Re: [onap-discuss] [modeling] Call for approval on the “obsolete legacy attributes/datatypes” proposal for the resource IM

[jessie jewitt]

Hi Xu-
   Maybe we can discuss this next week. Our feedback is our recommendation
on what we would like to see done. You and others may not agree, in which
case perhaps we need to have a poll. I didn't see any other comments.
-Jessie

On Sat, Jun 16, 2018 at 8:01 AM, yangxu (H)  wrote:

> Hi Jessie,
>
> My view for the comment:
> The proposal is to mark some attributes/datatypes, for the readers of the
> spec to know they are recommended not to use these attributes/datatypes any
> more and these items are to be removed in the future releases.
> It's not about setting up a whole lifecycle of the model or to use a
> particular term to represent this intention. So I suggest we seperate the
> two things.
> What we need to decide is whether we accept the intention and find a
> proper way to mark it.
> It's suggested to adopt IISOMI definitions to represent the intention for
> the sake of convenience. But I'm not convinced we should adopt the whole
> IISOMI guidelines to use its terms.
> If the comment is that we couldn't use IISOMI term without first accepting
> the related definitions, maybe we could use other term or have our own
> definition to ease the discussion.
> If the comment is that we need to first mark these items as "deprecate"
> before "obsolete" as IISOMI suggest, (i.e. object directly remove items in
> the next release)I would suggest you to discuss with Alex whether he (and
> other interested people)could accept it.
> Anyway, I encourage the proposer to discuss with Jessie to address her
> comments. Or we need to discuss it the next week.
>
> Best regards,
> Xu Yang
> *发件人：*jessie jewitt
> *收件人：*yangxu (H),
> *抄 送：*denghui (L),onap-discuss@lists.onap.org,onap-tsc,
> *时间：*2018-06-16 02:03:57
> *主 题：*Re: [onap-discuss][modeling] Call for approval on the “obsolete
> legacy attributes/datatypes” proposal for the resource IM
>
> Here is our (ARM/OAM Technologies) feedback on this proposal:
>
> 1. Format - We're glad to see that ONAP is using the "Applied Stereotypes"
> column in their tables, even though this is only defined in IFA015 output
> and not IFA011. However, since you are choosing to use it, we'd like to
> recommend that it be used properly. The column is intended to show the
> applied stereotypes that they use in Papyrus, which are based on the IISOMI
> Open Model Profile. See Stereotype Usage
>    for an explanation of
> how these stereotypes are used.  "Obsolete" is a stereotype itself and
> not a valid enum for "support".  The proper format per IISOMI would be:
>
> OpenModelAttribute   (this is the applied stereotype)
> isInvariant: false
> support: MANDATORY
> Obsolete  (this is the applied stereotype, note there is no "d" on the end)
>
> 2. Artifact lifecycle:  The proposal to put an artifact in an "Obsolete"
> lifecycle state implies that we have agreed to implement artifact
> lifecycles in accordance with the IISOMI Guidelines
>  . As far as
> we know, this is under discussion, but has not been accepted by the team.
> It seems a bit pre-mature, therefore, to jump straight to a proposal where
> we implement the "Obsolete" stereotype without having first accepted
> general use of the the lifecycle stereotypes.
>
> 3. Recommendation for moving forward on this proposal:
>  a. Implementing an artifact lifecycle, per this proposal, implies
> "agreement" that we will use artifact lifecycles in the model. If people
>agree to this proposal, then we have implicit agreement on
> using lifecycle stereotypes. No need for discussion. If this is not the
> case,
>  then we need to discuss and agree on usage of the lifecycle
> stereotypes before marking any artifact as "Obsolete".
>  b. Assuming it is agreed to use lifecycle stereotypes, all artifacts
> in the model should have a lifecycle phase associated to them, and not
>  just the proposed "Obsolete" lifecycle.
>  c.  The proposal to go from "nothing" to "Obsolete" is not in
> accordance with the
> lifecycle
> state machine
> 
>   that
> proposes an artifact go from  "Mature"-> "Deprecated"->
> "Obsolete". Assuming, had we implemented lifecycles, and that these
> attributes would be in a "Mature"   phase, the next logical step would
> be then to transition them to "Deprecated" and not "Obsolete", as proposed.
> We are not in agreement
>  that they directly be marked as "Obsolete".
>
>
> On Wed, Jun 13, 2018 at 11:38 PM, yangxu (H)  wrote:
>
>> Hi Jessie,
>>
>>
>>
>> Maybe I can help clarify this. Per the discussion of the resource IM
>> interest group, the “obsolete” is intended to follow the definitions of the
>> IISOMI modeling guidelines as you stated below for the time being.
>>
>> I think the intention of the proposa

[onap-discuss] 答复: VNF configuration via VFC

[Yan Yang]

Hi Rebecca,

 

Taking the VoLTE use case as an example, VNF configuration is completed
through the vendor EMS.

VF-C provides an component called EMS driver which can translate alarms and
performance received from the vendor EMS into VES format and report to DCAE
VESCollector.  Then the alarm is  received by the DCAE application, such as
Holmes(do alarm correlation ), then policy project will match the
corresponding policy, and then call action actor, such as VF-C to do heal.

 

Currently , VF-C does not support VNF configuration changes based on  alarm
close loop.

 

Best Regards,

Yan

发件人: onap-discuss-boun...@lists.onap.org
[mailto:onap-discuss-boun...@lists.onap.org] 代表 Rebecca Lantz
发送时间: 2018年6月14日 21:51
收件人: Singh Kalra, Mandeep; Huang, Haibin; Addepalli, Srinivasa R;
onap-discuss@lists.onap.org
主题: Re: [onap-discuss] VNF configuration via VFC

 

Hi,

 

I have a related question.

Assume I am using VFC with a S-VNFM for LCM.

And sure, I can use an external EM for configuration of my VNF.  (This is
the answer specified below)

 

However, how can I utilize ONAP for closed loops using my VNF specific
alarms and VNF specific configuration?   If there is something in my VNF
specific data model generating an alarm or counter (VES event) which I then
want a policy to have a configuration change sent to the VNF.

 

I believe this kind of closed loop could be done with APPC. If I am using
VFC do I also use APPC somehow for this scenario?

 

Thanks,

Rebecca

 

From: onap-discuss-boun...@lists.onap.org
 On Behalf Of Singh Kalra, Mandeep
Sent: Wednesday, June 13, 2018 11:24 PM
To: Huang, Haibin ; Addepalli, Srinivasa R
; onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] VNF configuration via VFC

 

Hi,

 

  Thanks a lot Srini and Haibin.

 

  vCPE use case which is TOSCA format create VNF via G-VNFM. We
are debugging it.

  >> Is the vCPE TOSCA part of Bejing release, the tosca
equivalent of vCPE uses VFC or ARIA ?

 

  And also for the VNF configuration as Srini mentioned EMS will
be used for VNF configuration but below statement is part of the approved
volte use case ::

As a stretch goal in VOLTE use case was the VNF configuration using ansible

>> What will be the approach here via VFC ?

 

 

 

Regards

Mandeep

 

From: Huang, Haibin [mailto:haibin.hu...@intel.com] 
Sent: Thursday, June 14, 2018 6:22 AM
To: Addepalli, Srinivasa R ; Singh Kalra,
Mandeep ; onap-discuss@lists.onap.org
Subject: [External] RE: VNF configuration via VFC

 

Hi Mandeep Sirinivasa,

 

vCPE use case which is TOSCA format create VNF via G-VNFM. We are debugging
it.

 

From: onap-discuss-boun...@lists.onap.org
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Addepalli,
Srinivasa R
Sent: Thursday, June 14, 2018 6:18 AM
To: Singh Kalra, Mandeep ;
onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] VNF configuration via VFC

 

Hi Mandeep,

 

We had same question a while ago when we are trying to figure out the
changes required in VF-C project to leverage HPA.

 

VOLTE team, please correct if this understanding is not right:

*   It appears that G-VNFM is not being leveraged to bring up VNFs.
*   Every VNF has its own sVNFM from the VNF vendor.

 

Due to this,  HPA team is felt that they should modify NSLCM (upper level
Micro Service that talks to G-VNFM or one of sVNFMs for a given VNF) to
integrate with OOF to get the best site and compute flavors. 

 

Also, I think there is a need to create VNF (may be using vFW) via G-VNFM
for testing any OOF features/policies.

 

On VNF configuration : As I understand, vendors are providing their own EMS
in addition to sVNFM for configuring the VNF applications.  I don’t think
APP-C is used to configure VOLTE VNFs. I may be wrong here. Please correct.

 

Thanks

Srini

 

 

From: onap-discuss-boun...@lists.onap.org
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Singh Kalra,
Mandeep
Sent: Wednesday, June 13, 2018 11:36 AM
To: onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] VNF configuration via VFC

 

Hi,

 

  Will appreciate some inputs on the below queries.

  And also if GVNFM is used in any of the use cases ?

 

 

Regards

Mandeep

From: Singh Kalra, Mandeep 
Sent: Tuesday, June 12, 2018 5:37 PM
To: onap-discuss@lists.onap.org
Subject: VNF configuration via VFC

 

Hi,

 

  

 I have a doubt about the VNF configuration through VFC.
After the VNFs are instantiated is there any interface/APIs using which the
VNFs can be configured ?

As a stretch goal in VOLTE use case was the VNF
configuration using ansible. 

  Can you please share your views on this ?

 

  Also, is the gvnfm used in any use case in R2 ?

 

Regards

Mandeep   

 

 

  _  


This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise confidentia

Re: [onap-discuss] Building blocks for multicloud k8s plugin, RE: [coe] Team meeting Agenda

[Addepalli, Srinivasa R]

Hi Tal,

Thank you for the email and really appreciate your offer to prove training 
material on golang.

Original K8S discussions started with treating K8S as VIM. But that is no 
longer true. Current K8S plugin leverages all features supported by K8S 
deployment. 

On the technical help on K8S plugin, we will certainly like to get your advice 
and let us talk on COE weekly calls. Also, I will be in Beijing. Let us touch 
base.

Thanks
Srini

Sent from my iPhone

> On Jun 15, 2018, at 18:28, Tal Liron  wrote:
> 
> Hi everyone,
> 
> I've been following the conversation silently for a while, but it might be 
> time to jump in --
> 
> I am working on a training tutorial for Go, for my own team, and would be 
> happy to pass it on to anyone involved in ONAP. It's meant for veterans like 
> you who just need some pointers for the main stumbling blocks of this 
> productive language.
> 
> In Beijing next week I will be giving two talks related to the technologies 
> discussed. In one, I will present a tool to deploy directly to Kubernetes 
> from TOSCA models. In the second, I will introduce "operators" as a way to 
> create domain-specific clustering in Kubernetes, which I think we'll be 
> seeing more and more of in the Kubernetes space. All of this work is in Go.
> 
> (For what it's worth -- despite finding Go extremely useful, I'm actually not 
> sure that Go is the best choice specifically for writing operators. I'll 
> discuss the issue in my talk.)
> 
> I can probably contribute more significantly to the COE project, but I must 
> be honest and say that I have serious concerns about its overall approach. I 
> am not convinced that it's fruitful to treat Kubernetes as a VIM. This is 
> especially apparent as we see more and more truly cloud-native services that 
> manage their own lifecycles. Not only do they know best, but the custom code 
> to self-manage (operators) is embedded within the service. (That's why it's 
> "cloud native".) There's just so much more to Kubernetes then deploying 
> replicated pods. As a small example, on topic: I can't see having the 
> ObjectMeta.Name as having meaning externally in all but the most trivial 
> Kubernetes applications.
> 
> I see that the COE project is moving forward confidently, so I hope we can 
> talk more and perhaps find ways in which I can work with you constructively. 
> I'm sure that despite disagreement we can find some overlap in our goals and 
> help make ONAP better.
> ___
> 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

Re: [onap-discuss] [it-infrastructure-alerts] JIRA security maintainance. Saturday June 16 at 8am Pacific (3pm UTC)

[Jessica Wagantall]

This is now completed

Thanks
Jess

On Sat, Jun 16, 2018, 7:51 AM Jessica Wagantall <
jwagant...@linuxfoundation.org> wrote:

> Dear team
>
> This maintainance is about to start
>
> Thanks
> Jess
>
> On Fri, Jun 15, 2018, 12:39 PM Jessica Wagantall <
> jwagant...@linuxfoundation.org> wrote:
>
>> Dear team,
>>
>> This is just a small reminder of this upcoming maintenance.
>>
>> Thanks!
>> Jess
>>
>> On Wed, Jun 13, 2018 at 2:42 PM, Jessica Wagantall <
>> jwagant...@linuxfoundation.org> wrote:
>>
>>> What: The Linux Foundation will be performing a JIRA security upgrade
>>>
>>> When: Saturday June 16 at 8am Pacific (3pm UTC)
>>>
>>> Why:The bundled Atlassian OAuth plugin allows arbitrary HTTP requests to
>>> be proxied
>>> CVE-2017-9506 (https://jira.atlassian.com/browse/JRASERVER-65862)
>>>
>>> Impact: Jira will be unavailable for 1 hour
>>>
>>> Notices will be posted to the mailing lists at the start and end of the
>>> maintenance.
>>>
>>
>>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [modeling] Call for approval on the “obsolete legacy attributes/datatypes” proposal for the resource IM

[yangxu (H)]

Hi Jessie,

My view for the comment:
The proposal is to mark some attributes/datatypes, for the readers of the spec 
to know they are recommended not to use these attributes/datatypes any more and 
these items are to be removed in the future releases.
It's not about setting up a whole lifecycle of the model or to use a particular 
term to represent this intention. So I suggest we seperate the two things.
What we need to decide is whether we accept the intention and find a proper way 
to mark it.
It's suggested to adopt IISOMI definitions to represent the intention for the 
sake of convenience. But I'm not convinced we should adopt the whole IISOMI 
guidelines to use its terms.
If the comment is that we couldn't use IISOMI term without first accepting the 
related definitions, maybe we could use other term or have our own definition 
to ease the discussion.
If the comment is that we need to first mark these items as "deprecate" before 
"obsolete" as IISOMI suggest, (i.e. object directly remove items in the next 
release)I would suggest you to discuss with Alex whether he (and other 
interested people)could accept it.
Anyway, I encourage the proposer to discuss with Jessie to address her 
comments. Or we need to discuss it the next week.

Best regards,
Xu Yang
发件人：jessie jewitt
收件人：yangxu (H),
抄 送：denghui (L),onap-discuss@lists.onap.org,onap-tsc,
时间：2018-06-16 02:03:57
主 题：Re: [onap-discuss][modeling] Call for approval on the “obsolete legacy 
attributes/datatypes” proposal for the resource IM

Here is our (ARM/OAM Technologies) feedback on this proposal:

1. Format - We're glad to see that ONAP is using the "Applied Stereotypes" 
column in their tables, even though this is only defined in IFA015 output and 
not IFA011. However, since you are choosing to use it, we'd like to recommend 
that it be used properly. The column is intended to show the applied 
stereotypes that they use in Papyrus, which are based on the IISOMI Open Model 
Profile. See Stereotype Usage   
for an explanation of how these stereotypes are used.  "Obsolete" is a 
stereotype itself and not a valid enum for "support".  The proper format per 
IISOMI would be:

OpenModelAttribute   (this is the applied stereotype)
isInvariant: false
support: MANDATORY
Obsolete  (this is the applied stereotype, note there is no "d" on the end)

2. Artifact lifecycle:  The proposal to put an artifact in an "Obsolete" 
lifecycle state implies that we have agreed to implement artifact lifecycles in 
accordance with the IISOMI 
Guidelines . As 
far as we know, this is under discussion, but has not been accepted by the 
team. It seems a bit pre-mature, therefore, to jump straight to a proposal 
where we implement the "Obsolete" stereotype without having first accepted 
general use of the the lifecycle stereotypes.

3. Recommendation for moving forward on this proposal:
 a. Implementing an artifact lifecycle, per this proposal, implies 
"agreement" that we will use artifact lifecycles in the model. If people
   agree to this proposal, then we have implicit agreement on using 
lifecycle stereotypes. No need for discussion. If this is not the case,
 then we need to discuss and agree on usage of the lifecycle stereotypes 
before marking any artifact as "Obsolete".
 b. Assuming it is agreed to use lifecycle stereotypes, all artifacts in 
the model should have a lifecycle phase associated to them, and not   
just the proposed "Obsolete" lifecycle.
 c.  The proposal to go from "nothing" to "Obsolete" is not in accordance 
with the 
 
lifecycle state 
machine
  that proposes an artifact go from  "Mature"-> "Deprecated"-> 
"Obsolete". Assuming, had we implemented lifecycles, and that these attributes 
would be in a "Mature"   phase, the next logical step would be then to 
transition them to "Deprecated" and not "Obsolete", as proposed. We are not in 
agreement
 that they directly be marked as "Obsolete".
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]


On Wed, Jun 13, 2018 at 11:38 PM, yangxu (H) 
mailto:yang...@huawei.com>> wrote:
Hi Jessie,

Maybe I can help clarify this. Per the discussion of the resource IM interest 
group, the “obsolete” is intended to follow the definitions of the IISOMI 
modeling guidelines as you stated below for the time being.
I think the intention of the proposal is to mark those attributes/datatypes as 
“obsolete” but not removed for R3, and perhaps remove them in R4, which fits 
the definition. Alex, you can confirm whether I interpreted it correctly.

For others who haven’t attend the resource IM call, please noted that the 
“lifecycle” stereotype of the model is still under discussion. The interes

Re: [onap-discuss] [it-infrastructure-alerts] JIRA security maintainance. Saturday June 16 at 8am Pacific (3pm UTC)

[Jessica Wagantall]

Dear team

This maintainance is about to start

Thanks
Jess

On Fri, Jun 15, 2018, 12:39 PM Jessica Wagantall <
jwagant...@linuxfoundation.org> wrote:

> Dear team,
>
> This is just a small reminder of this upcoming maintenance.
>
> Thanks!
> Jess
>
> On Wed, Jun 13, 2018 at 2:42 PM, Jessica Wagantall <
> jwagant...@linuxfoundation.org> wrote:
>
>> What: The Linux Foundation will be performing a JIRA security upgrade
>>
>> When: Saturday June 16 at 8am Pacific (3pm UTC)
>>
>> Why:The bundled Atlassian OAuth plugin allows arbitrary HTTP requests to
>> be proxied
>> CVE-2017-9506 (https://jira.atlassian.com/browse/JRASERVER-65862)
>>
>> Impact: Jira will be unavailable for 1 hour
>>
>> Notices will be posted to the mailing lists at the start and end of the
>> maintenance.
>>
>
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss