Re: [E] Re: [onap-discuss] [cia] Towards better container images in ONAP

[Michael Still]

On Sat, Aug 18, 2018 at 4:12 AM Viswanath V Kumar Skand Priya <
viswanath.kumarskandpr...@verizon.com> wrote:

> Hi Tal / All,
>
> Thanks for starting this thread to address this important issue and I
> second both Tal's & Michael's view as well. Infact we are now currently
> breaking our heads to bring up ONAP "behind corporate proxies" and almost
> 80% of operational issue which we always run into is this internet
> dependencies.
>

I was thinking about this more over the weekend, and I am starting to think
that a process like this would work reasonably:

- Create a repo for "official ONAP base images", basing the contents off
what is currently used in OOM -- so for example if there are lots of users
of Ubuntu 16.04, then we just create a ubuntu-lts image in said repo.

- Rebase existing Dockerfiles to use the official base image which maps to
their current base.

This at least makes it clearer what we're using, as well as making it
easier to then "push dependancies down" into those central base images. I
think its pretty clear that we need to simplify what we depend on (15
different JDK base images right now, 11 different specifications for the
Ubuntu version, etc).

I'm not opposed to letting deployers substitute their chosen SOE images in
for the central ones, and having those all in one place would certainly
make that easier.

For reference, there are 96 unique "FROM" lines in ONAP Dockerfiles at the
moment.

Thoughts?

Michael

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

View/Reply Online (#11937): https://lists.onap.org/g/onap-discuss/message/11937
Mute This Topic: https://lists.onap.org/mt/24626855/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-discuss] [cia] Towards better container images in ONAP

[Michael Still]

On Fri, Aug 10, 2018 at 5:17 AM Tal Liron  wrote:

> Hi everyone,
>
> My colleague Leif Madsen and I have done some research and I'd like to
> present our conclusions as an opening to discussion. If there's interest in
> this, we are happy to also do a proof-of-concept to show how this would
> look in practice.
>

Thanks for starting this thread -- I think its an important conversation
and one I am personally interested in helping out with, especially if we
can get over the desire to have meetings in the middle of the night.

I think there's another factor in play here that I want to make sure is on
your radar. I don't know about in other countries, but I am yet to
encounter a non-trivial enterprise in Australia which gives their
production environments internet access. At the moment several ONAP
components run shell scripts on start which pull packages from the internet
(either OS packages, or python pip packages). This simply wont work in many
production environments -- as well as meaning that operations staff don't
know what version of the software they're running any more.

I'd like to see those dependancies pushed into the container images more
formally during the build process. Perhaps that's something we can solve at
the same time?

Thanks,
Michael

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

View/Reply Online (#11917): https://lists.onap.org/g/onap-discuss/message/11917
Mute This Topic: https://lists.onap.org/mt/24242182/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-discuss] [cia] Towards better container images in ONAP

[Michael Still]

I'd appreciate this conversation being in email as much as possible -- some
of us are in radically different timezones and can't just attend meetings
at 3am willy nilly.

Thanks,
Michael

On Fri, Aug 10, 2018 at 10:53 AM Tal Liron  wrote:

> Thanks, Adolfo, I will. But I will personally insist on keeping as much
> discussion as possible on email. ONAP is a large project spanning all the
> time zones, and not everybody has time in their work to join the 50+
> meetings ONAP has per week. Email, for all its faults, remains our most
> inclusive medium.
>
> On Thu, Aug 9, 2018 at 7:14 PM Adolfo Perez-Duran <
> adolfo.perez-du...@oamtechnologies.com> wrote:
>
>> Tal,
>>
>> Thanks for sharing your proposal.
>>
>> I invite you to socialize and discuss your proposed approach with the CIA
>> team during our next meeting.
>>
>> Our next meeting is Wednesday August 15th at 6:00 pm MT.
>>
>> Cheers,
>>
>> Adolfo
>>
>>
>> On Aug 9, 2018 13:17, "Tal Liron"  wrote:
>>
>> Hi everyone,
>>
>> My colleague Leif Madsen and I have done some research and I'd like to
>> present our conclusions as an opening to discussion. If there's interest in
>> this, we are happy to also do a proof-of-concept to show how this would
>> look in practice.
>>
>> *STATEMENT OF PROBLEM*
>>
>> We all know that ONAP lacks uniformity in images, leading to a broad mix
>> of operating systems, packages, versions, and ultimately an unwieldy
>> repository requiring many gigabytes of storage and network data transfer to
>> stand up. But actually the problem is more serious.
>>
>> ONAP-provided official images can only ever be considered as reference
>> images. No IT department of any company would approve of deploying complete
>> ready-to-run images downloaded off the Internet, even from a trusted Linux
>> Foundation hosted repository. Remember that these images contain not only
>> our ONAP code, but also many other operating system and additional
>> packages. This includes high-level components such as MariaDB/MySQL,
>> language runtimes such as OpenJDK and Python, and low-level system
>> components such as glib and OpenSSL. Companies have their own security and
>> certification processes in place for vetting/patching these packages, and
>> indeed licensing and support contracts for many of them. It's thus
>> important that ONAP provide not only useful reference images, but also a
>> way for companies' IT departments to build their own images in their own
>> integration/testing/staging environment using their own vendored operating
>> systems and packages.
>>
>> A secondary problem is that we are not currently using open standards.
>> While Docker build configuration and images are a "de facto" standard in
>> the container world, they are problematic outside of Docker products. We
>> should be using the OCI format , which
>> is also endorsed by Docker Inc and natively supported by Docker software.
>> This will allow users to not only build images themselves, but also allow
>> them to choose toolchains other than Docker.
>>
>> *POSSIBLE SOLUTIONS*
>>
>> One suggestion is that we move all the image building to a single,
>> centralized ONAP repository. This would allow users to manage images in one
>> place. Unfortunately, this seems unrealistic. It would greatly slow down
>> development work in individual projects and likely lead to painful bugs due
>> to version mismatches between repos. Also, it's not a completely satisfying
>> solution, because users would still have to go over dozens of complex image
>> descriptors, and would have to repeat this process for every release of
>> ONAP. Users who want to track our master repos will find this constant
>> patching to be impossibly cumbersome.
>>
>> A better solution would be a combination of technology and policy. The
>> idea is that we require all ONAP projects to derive their images from a set
>> of conventionally named base images. This decoupling would allow users to
>> replace these bases images with images of their choosing. But, in order for
>> this to work as intended, we must also require that ONAP projects not be
>> allowed to install additional packages over this base image. Adding
>> packages would not only break the decoupling, but would also not be
>> portable across base operating systems.
>>
>> For an example, let's look at a Dockerfile in the SO project. It begins
>> with this line stating the base image:
>>
>> FROM openjdk:8-jdk-alpine
>>
>> Already two important choices are made here: basing it off the latest
>> publicly available version of Alpine Linux, and also using a specific build
>> and distribution (and latest version) of OpenJDK. Both are limiting and
>> problematic choices. Instead we can do something like this:
>>
>> FROM onap-base/java8:2.0
>>
>> So, what we are saying here is that the basic "onap/java8" image should
>> contain the operating system and packages to support Java 8 applications.
>> For the ONAP reference images, this could be Alpine 

[onap-discuss] [AAI] Changes to released v13 API

[Michael Still]

Hi,

I've just noticed that https://gerrit.onap.org/r/#/c/56937/ changes the v13
API as released in ONAP Beijing. The changes look additive to me, but it
makes me wonder what ONAP's policy is on API stability.

Is it normal for a released API version to be changed?

I can't see any discussion in the associated Jira issue about why this
wasn't done as a v14 of the API, which is why I am asking this question in
public.

Thanks,
Michael

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

View/Reply Online (#11914): https://lists.onap.org/g/onap-discuss/message/11914
Mute This Topic: https://lists.onap.org/mt/24576103/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-discuss] [aai] Process for chaning the AAI OXM in an OOM world

[Michael Still]

Thanks for the reply. Unfortunately, the AAI calls are at a bad time for me
due to timezones (2am my time), so that's not going to work.

I'll send you an off list email with a description of what we're trying to
do and perhaps we could setup a separate call?

Thanks,
Michael



On Tue, Jul 3, 2018 at 6:16 AM FORSYTH, JAMES  wrote:

> Hi, Michael,
>
>
>
> Thanks for your interest in AAI!  We don’t have an IRC chat channel for
> AAI, but adding [aai] to messages sent to the onap-discuss list will allow
> those who are not interested in AAI to filter out the email.
>
>
>
> As far as changing the schema goes, it’s not for the faint of heart – the
> schema and edge rules that are currently in the aai-common repo represent
> several years of experience in ECOMP, OpenECOMP, and ONAP development and
> changes to java types and edge rules can have cascading impact which can
> break adjacent systems and workflows.
>
>
>
> That said, our docker images are created by Jenkins, example job:
> https://jenkins.onap.org/view/aai-resources/job/aai-resources-beijing-docker-java-daily/
> I suppose you could mount your own schema oxm in the helm chart; there’s
> multiple places that use those files, the critical one would be
> aai-resources.
>
>
>
> I recommend you follow our wiki space here:
>
>
>
> https://wiki.onap.org/x/aIsx
>
>
>
> And join our weekly calls:
>
>
>
> https://wiki.onap.org/x/4oCk
>
>
>
> I don’t think we’ll be meeting Wednesday because of the US holiday, but
> please join us next week.
>
>
>
> Thanks,
>
> jimmy
>
>
>
>
>
>
>
> *From: * on behalf of Michael Still <
> mi...@stillhq.com>
> *Date: *Sunday, July 1, 2018 at 8:14 PM
> *To: *"onap-discuss@lists.onap.org" 
> *Subject: *Re: [onap-discuss] Process for chaning the AAI OXM in an OOM
> world
>
>
>
> I guess alternatively if editing the OXM is a terrible idea (and that
> might explain why it isn't documented), I'd appreciate a chat with someone
> on the AAI side about how to better implement what we need. Is there an
> equivalent of an IRC chat channel for the AAI team I could join to talk to
> people?
>
>
> Thanks,
>
> Michael
>
>
>
> On Mon, Jul 2, 2018 at 6:36 AM Michael Still  wrote:
>
> Hi,
>
>
>
> I'm working through a PoC deployment of ONAP at the moment, and one of the
> things we've identified as likely to be required is editing the AAI OXM to
> include additional attributes for some of the nodes.
>
>
>
> I've found https://wiki.onap.org/pages/viewpage.action?pageId=10783023
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_pages_viewpage.action-3FpageId-3D10783023=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=Oej6QUk5p2KdqNEWySpOHA=nV1SH_gKrvZPpfeuHI9FMKfgOXaDhx9c_AMXzWfJnkE=eCKjmcEAt10Bcj0UVBMxsaI9Nh22z5mV6U0fSMTh0Io=>
> which has documentation on how to do this from a developer perspective, but
> I can't find a documented process that walks from that edit through to
> having built new docker images that OOM can then launch. I'm comfortable
> with running a local Docker image repository, but I can't see AAI's Docker
> build process documented anywhere.
>
>
>
> Is there documentation on this somewhere I haven't managed to find?
>
>
>
> Thanks,
>
> Michael
>
>
>
> --
>
> Did this email leave you hoping to cause me pain? Good news!
>
> Sponsor me in city2surf 2018 and I promise to suffer greatly.
>
> http://www.madebymikal.com/city2surf-2018/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.madebymikal.com_city2surf-2D2018_=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=Oej6QUk5p2KdqNEWySpOHA=nV1SH_gKrvZPpfeuHI9FMKfgOXaDhx9c_AMXzWfJnkE=yJcHGw6GTwwTdjPN-qgrn8Bvpey-lUmj5oGrgJuUCjo=>
>
>
>
>
> --
>
> Did this email leave you hoping to cause me pain? Good news!
>
> Sponsor me in city2surf 2018 and I promise to suffer greatly.
>
> http://www.madebymikal.com/city2surf-2018/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.madebymikal.com_city2surf-2D2018_=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=Oej6QUk5p2KdqNEWySpOHA=nV1SH_gKrvZPpfeuHI9FMKfgOXaDhx9c_AMXzWfJnkE=yJcHGw6GTwwTdjPN-qgrn8Bvpey-lUmj5oGrgJuUCjo=>
>
> 
>


-- 
Did this email leave you hoping to cause me pain? Good news!
Sponsor me in city2surf 2018 and I promise to suffer greatly.
http://www.madebymikal.com/city2surf-2018/

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

View/Reply Online (#10813): https://lists.onap.org/g/onap-discuss/message/10813
Mute This Topic: https://lists.onap.org/mt/23006155/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-discuss] Process for chaning the AAI OXM in an OOM world

[Michael Still]

I guess alternatively if editing the OXM is a terrible idea (and that might
explain why it isn't documented), I'd appreciate a chat with someone on the
AAI side about how to better implement what we need. Is there an equivalent
of an IRC chat channel for the AAI team I could join to talk to people?

Thanks,
Michael

On Mon, Jul 2, 2018 at 6:36 AM Michael Still  wrote:

> Hi,
>
> I'm working through a PoC deployment of ONAP at the moment, and one of the
> things we've identified as likely to be required is editing the AAI OXM to
> include additional attributes for some of the nodes.
>
> I've found https://wiki.onap.org/pages/viewpage.action?pageId=10783023
> which has documentation on how to do this from a developer perspective, but
> I can't find a documented process that walks from that edit through to
> having built new docker images that OOM can then launch. I'm comfortable
> with running a local Docker image repository, but I can't see AAI's Docker
> build process documented anywhere.
>
> Is there documentation on this somewhere I haven't managed to find?
>
> Thanks,
> Michael
>
> --
> Did this email leave you hoping to cause me pain? Good news!
> Sponsor me in city2surf 2018 and I promise to suffer greatly.
> http://www.madebymikal.com/city2surf-2018/
>


-- 
Did this email leave you hoping to cause me pain? Good news!
Sponsor me in city2surf 2018 and I promise to suffer greatly.
http://www.madebymikal.com/city2surf-2018/

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

View/Reply Online (#10723): https://lists.onap.org/g/onap-discuss/message/10723
Mute This Topic: https://lists.onap.org/mt/22996551/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[onap-discuss] Process for chaning the AAI OXM in an OOM world

[Michael Still]

Hi,

I'm working through a PoC deployment of ONAP at the moment, and one of the
things we've identified as likely to be required is editing the AAI OXM to
include additional attributes for some of the nodes.

I've found https://wiki.onap.org/pages/viewpage.action?pageId=10783023
which has documentation on how to do this from a developer perspective, but
I can't find a documented process that walks from that edit through to
having built new docker images that OOM can then launch. I'm comfortable
with running a local Docker image repository, but I can't see AAI's Docker
build process documented anywhere.

Is there documentation on this somewhere I haven't managed to find?

Thanks,
Michael

-- 
Did this email leave you hoping to cause me pain? Good news!
Sponsor me in city2surf 2018 and I promise to suffer greatly.
http://www.madebymikal.com/city2surf-2018/

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

View/Reply Online (#10722): https://lists.onap.org/g/onap-discuss/message/10722
Mute This Topic: https://lists.onap.org/mt/22996551/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[onap-discuss] Searching for known issues in ONAP Beijing?

[Michael Still]

Hi,

I'm in the process of planning an ONAP Beijing deployment, and as part of
that I'd like to be able to see known bugs for that release. However, I
haven't managed to figure out how to construct a search for that in Jira.

So -- a couple of questions:

* what is the plan for back porting bug fixes to the Beijing stable branch?
* is there a tag (or similar) in Jira which identifies bugs which have been
identified as requiring such a back port?

Thanks,
Michael

-- 
Did this email leave you hoping to cause me pain? Good news!
Sponsor me in city2surf 2018 and I promise to suffer greatly.
http://www.madebymikal.com/city2surf-2018/

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

View/Reply Online (#10508): https://lists.onap.org/g/onap-discuss/message/10508
Mute This Topic: https://lists.onap.org/mt/22563519/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-discuss] AAF kubernetes pods failing

[Michael Still]

Thanks for this. You're totally right, I didn't have a shared NFS mount
across the kubelets. Interestingly I can't see this mentioned in the
getting started guide or the install guide. I concede its in the kube setup
guide though.

Is there are good reason that OOM isn't using more traditional persistent
volume claims via kubernetes storage providers?

Thanks,
Michael

On Tue, Jun 19, 2018 at 5:24 PM Michal Ptacek 
wrote:

> Hi,
>
>
>
> I believe that this problem might be caused by missing mountpoint
> /opt/app/osaaf
>
> this might pop-up when nfs share is not established across computes
>
> see "Setting up an NFS share for Multinode Kubernetes Clusters" in
>
> ​
> http://onap.readthedocs.io/en/latest/submodules/oom.git/docs/oom_setup_kubernetes_rancher.html#onap-on-kubernetes-with-rancher
>
>
>
> br,
>
> Michal
>
>
>
> - *Original Message* -
>
> *Sender* : Michael Still 
>
> *Date* : 2018-06-19 04:57 (GMT+1)
>
> *Title* : Re: [onap-discuss] AAF kubernetes pods failing
>
> *To : *wkurki...@gmail.com
>
> *CC : *onap-discuss@lists.onap.org
>
>
>
> Hi, I am seeing exactly this problem today with an attempted Beijing
> install using OOM. The aaf-locate container is logging:
>
>
>
> /bin/bash: /opt/app/osaaf/logs/locate/stdout`date -I`: No such file or
> directory
>
>
>
> Has anyone found a work-around for this?
>
>
>
> Thanks,
>
> Michael
>
>
>
>
>
>
>
> On Sat, May 12, 2018 at 6:48 AM William Kurkian 
> wrote:
>
> Hello,
>
>
>
> On my onap install, most of the AAF pods are not starting. It seems to be
> largely because of one pod that has an error sending it into
> CrashLoopBackoff. It is the aaf-locate pod and it gets this error:
>
>
>
> /bin/bash: /opt/app/osaaf/logs/locate/stdout`date -I`: No such file or
> directory
>
>
>
> Is this known and expected?  or is it some issue on my machine?
>
>
>
> Thanks,
>
> William Kurkian
>
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
>
>
>  --
>
> Did this email leave you hoping to cause me pain? Good news!
>
> Sponsor me in city2surf 2018 and I promise to suffer greatly.
>
> http://www.madebymikal.com/city2surf-2018/
>
> ___
>
> onap-discuss mailing list
>
> onap-discuss@lists.onap.org
>
> https://lists.onap.org/mailman/listinfo/onap-discuss
>
>
>
>
>
>
>


-- 
Did this email leave you hoping to cause me pain? Good news!
Sponsor me in city2surf 2018 and I promise to suffer greatly.
http://www.madebymikal.com/city2surf-2018/
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] AAF kubernetes pods failing

[Michael Still]

Hi, I am seeing exactly this problem today with an attempted Beijing
install using OOM. The aaf-locate container is logging:

/bin/bash: /opt/app/osaaf/logs/locate/stdout`date -I`: No such file or
directory

Has anyone found a work-around for this?

Thanks,
Michael



On Sat, May 12, 2018 at 6:48 AM William Kurkian  wrote:

> Hello,
>
> On my onap install, most of the AAF pods are not starting. It seems to be
> largely because of one pod that has an error sending it into
> CrashLoopBackoff. It is the aaf-locate pod and it gets this error:
>
> /bin/bash: /opt/app/osaaf/logs/locate/stdout`date -I`: No such file or
> directory
>
> Is this known and expected?  or is it some issue on my machine?
>
> Thanks,
> William Kurkian
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
>


-- 
Did this email leave you hoping to cause me pain? Good news!
Sponsor me in city2surf 2018 and I promise to suffer greatly.
http://www.madebymikal.com/city2surf-2018/
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Fixing invalid YAML in read only git repos

[Michael Still]

Sure but my point is that the YAML should at least be valid. There are many
repos in this state. It would be nice to be able to programmatically
exclude these repos from my scripts, but I can't do that with the YAML
content as it stands now.

Michael

On Sat., 19 May 2018, 4:02 am Gildas Lanilis, <gildas.lani...@huawei.com>
wrote:

> Hi Michael,
>
>
>
> Aai-config repo is no longer used by AAI Team, and thus the repo has been
> locked.
>
> You can use this link to see status of the repo in Gerrit:
> https://gerrit.onap.org/r/#/admin/projects/?filter=aai
>
>
>
>
>
> Thanks,
>
> Gildas
>
> ONAP Release Manager
>
> 1 415 238 6287
>
>
>
> *From:* onap-discuss-boun...@lists.onap.org [mailto:
> onap-discuss-boun...@lists.onap.org] *On Behalf Of *Michael Still
> *Sent:* Wednesday, May 16, 2018 6:01 PM
> *To:* onap-discuss@lists.onap.org
> *Subject:* [onap-discuss] Fixing invalid YAML in read only git repos
>
>
>
> Hi,
>
>
>
> the INFO.yaml file in aai/aai-config is syntactically invalid, as are
> several others. I figured I'd just fix this, but my review was rejected
> because the repo is marked as read only:
>
>
>
> $ git review
>
> Could not connect to gerrit.
>
> Enter your gerrit username: mikal
>
> Trying again with ssh://mi...@gerrit.onap.org:29418/aai/aai-config.git
>
> Creating a git remote called "gerrit" that maps to:
>
>ssh://mi...@gerrit.onap.org:29418/aai/aai-config.git
>
>
>
> This repository is now set up for use with git-review. You can set the
>
> default username for future repositories with:
>
>   git config --global --add gitreview.username "mikal"
>
>
>
> Your change was committed before the commit hook was installed.
>
> Amending the commit to add a gerrit change id.
>
> remote: Processing changes: refs: 1, done
>
> To ssh://mi...@gerrit.onap.org:29418/aai/aai-config.git
>
>  ! [remote rejected] HEAD -> refs/publish/master (project is read only)
>
> error: failed to push some refs to 'ssh://
> mi...@gerrit.onap.org:29418/aai/aai-config.git'
>
>
>
> Having valid YAML in these info files would be useful to me as I starting
> to write simple scripts that try to use this information. Is there any path
> to getting these files fixed?
>
>
>
> Thanks,
>
> Michael
>
>
>
> --
>
> Did this email leave you hoping to cause me pain? Good news!
>
> Sponsor me in city2surf 2018 and I promise to suffer greatly.
>
> http://www.madebymikal.com/city2surf-2018/
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] Fixing invalid YAML in read only git repos

[Michael Still]

Hi,

the INFO.yaml file in aai/aai-config is syntactically invalid, as are
several others. I figured I'd just fix this, but my review was rejected
because the repo is marked as read only:

$ git review

Could not connect to gerrit.

Enter your gerrit username: mikal

Trying again with ssh://mi...@gerrit.onap.org:29418/aai/aai-config.git

Creating a git remote called "gerrit" that maps to:

ssh://mi...@gerrit.onap.org:29418/aai/aai-config.git


This repository is now set up for use with git-review. You can set the

default username for future repositories with:

  git config --global --add gitreview.username "mikal"


Your change was committed before the commit hook was installed.

Amending the commit to add a gerrit change id.

remote: Processing changes: refs: 1, done

To ssh://mi...@gerrit.onap.org:29418/aai/aai-config.git

 ! [remote rejected] HEAD -> refs/publish/master (project is read only)

error: failed to push some refs to 'ssh://
mi...@gerrit.onap.org:29418/aai/aai-config.git'

Having valid YAML in these info files would be useful to me as I starting
to write simple scripts that try to use this information. Is there any path
to getting these files fixed?

Thanks,
Michael

-- 
Did this email leave you hoping to cause me pain? Good news!
Sponsor me in city2surf 2018 and I promise to suffer greatly.
http://www.madebymikal.com/city2surf-2018/
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [AAI] Modelling physical hardware in ONAP AAI

[Michael Still]

Thanks so much to both of you for your very helpful comments. I'm going to
take some time today to digest them and then will come back with further
questions.

Thanks again,
Michael

On Tue, Nov 21, 2017 at 5:29 AM, FORSYTH, JAMES <jf2...@att.com> wrote:

> Hi, Michael,
>
>
>
> According to AAI SMEs, this is the way to do it:
>
>
>
> 1. SDN switch by Pnf
>
> 2. SDN switch port by p-interface and l-interface(s)
>
> 3. Physical links and logical links between SDN port switches by
> physicallinks and logicallinks
>
> 4. SDN switch locations by complexes.
>
> 5. If the SDN control plane is segmented (partitioned, sharded), perhaps
> cloud-region can be used to represent the segments. Cloud-region is meant
> to represent the segmentation of the cloud management plane, so if the
> boundaries of SDN control and cloud management plane do not coincide, we
> may need some further modeling.
>
> 6. Since the ONAP model can change in the future, it would be good if the
> modelers of the SDN switches  network bring their solution to ONAP.
>
>
>
> Thanks,
>
> jimmy
>
>
>
> *From:* onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-bounces@
> lists.onap.org] *On Behalf Of *Michael Still
> *Sent:* Sunday, November 19, 2017 11:29 PM
> *To:* onap-discuss@lists.onap.org
> *Subject:* [onap-discuss] [AAI] Modelling physical hardware in ONAP AAI
>
>
>
> Hi,
>
>
>
> I have a use case where we are managing a network of SDN switches. We
> would like to use ONAP AAI to handle the inventory management for ports on
> these switches, as well as modelling which switches are in what locations
> (and how they interconnect with each other).
>
>
>
> I haven't been able to find any examples of how I would do such a thing in
> AAI, although its entirely possible that I've missed something obvious.
> Does the team have any pointers on getting started?
>
>
>
> Thanks,
>
> Michael
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] Clarifying the TSC selected branching model for Amsterdam

[Michael Still]

Hi,

so I've been watching the video of the 9 November TSC meeting, and find the
discussion of the branching model for Amsterdam quite interesting. Is this
documented anywhere on the wiki? I ask because I have a couple of questions:

 - my understanding of the stated plan is that Amsterdam will be a stable
branch off master at release time
 - that branch will receive back ported bug fixes and security fixes from
master
 - _all_ bug fixes will be back ported, not just high priority changes
 - features added in master will _not_ be back ported to the Amsterdam
stable branch

I'm a bit confused about the discussion of a one month maintenance release
for Amsterdam. Does that imply back ports stop after that maintenance
release? Or is that just the timeline for the _first_ maintenance release?

What about when Beijing is released? Is it another stable branch off
master? When Beijing is released, will that cause maintenance back ports to
the Amsterdam stable branch to cease?

For reference, I am quite familiar with the OpenStack stable branch model,
which is quite similar in some respects. The OpenStack community has a
sliding window for what gets back ported, as documented at
https://docs.openstack.org/project-team-guide/stable-branches.html .
OpenStack supports two previous releases as stable branches, but the
consistent feedback from the operator community is that they'd like to see
that period extended. The reason this hasn't happened is mainly developer
resources (but also some technical limitations around gating).

Another interesting difference is that OpenStack has a policy of only back
porting to stable branches, they never write new code directly against a
stable branch. Does the TSC have a read on what they want to do there?

As ONAP becomes more widely adopted there will be pressure from operators
to provide supported releases for longer periods, so being clear on all
this from the outset seems wise.

Thanks,
Michael
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Failed demo install using "openstack vanilla" heat template

[Michael Still]

The download issue sounds like a networking problem on your end, I haven't
seen anything like that in my testing.

Cheers,
Michael

On Thu, Nov 2, 2017 at 1:53 AM, Gaurav Gupta (c) <guptagau...@vmware.com>
wrote:

> Michael
>
>
> We had  the same issue and followed your suggestion and were ok .  thanks
> for the same
>
>
> Aparently have you tried  < running curl command > in isolation  and did
> you observe your download speed of pulling docker-compose.yml .We have
> noticed that everytime it drops to "zero" or low values . there are issues
> in pulling docker-compose.yml file completely . We tried it 2-3 times and
> we see same behaviour .
>
> We are trying to establish where and why  is this coming from  .
>
> Is this due to -- Load on the Server where docker-compose.yml residing
>  being High ?>  or
>
>  or Big file size plays  a Role ?  or there is something in the
> infrastructure and environment that is causing this intermittent
> behaviour .  .
>
>
> thanks
>
> Gaurav
> --
> *From:* onap-discuss-boun...@lists.onap.org <onap-discuss-bounces@lists.
> onap.org> on behalf of Michael Still <mi...@stillhq.com>
> *Sent:* 31 October 2017 06:29
> *To:* onap-discuss@lists.onap.org
> *Subject:* [onap-discuss] Failed demo install using "openstack vanilla"
> heat template
>
> Hi,
>
> I am using the openstack vanilla heat templates [1] to bring up an ONAP
> demo stack using Vexxhost. The stack comes up just fine, but the portal
> doesn't appear to install correctly. When I run the portal_install.sh
> script manually, I get the following errors:
>
> -
>
> + /opt/docker/docker-compose down
>
> ERROR: The Compose file './docker-compose.yml' is invalid because:
>
> Unsupported config option for services.portal-db: 'healthcheck'
>
> services.portal-wms.depends_on contains an invalid type, it should be an
> array
>
> services.portal-apps.depends_on contains an invalid type, it should be an
> array
>
> + /opt/docker/docker-compose up -d
>
> ERROR: The Compose file './docker-compose.yml' is invalid because:
>
> Unsupported config option for services.portal-db: 'healthcheck'
>
> services.portal-wms.depends_on contains an invalid type, it should be an
> array
>
> services.portal-apps.depends_on contains an invalid type, it should be an
> array
>
> -
>
> This docker bug [2] implies that I should specify version 2.1 of docker
> compose for the portal, but that's already done. However, using version
> 1.16.1 of docker-compose instead of 1.9 seems to fix the problem.
>
> Is anyone else seeing these errors? Is the openstack vanilla heat template
> known to be currently working, or am I doing something weird?
>
> Thanks heaps,
> Michael
>
>
>
> 1: Specifically https://gerrit.onap.org/r/gitweb?p=demo.git;
> a=blob;f=heat/ONAP/onap_openstack.env;h=6a1593f5e4cf456b5d86d5464dd0fa
> ec59ad3e04;hb=master
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_gitweb-3Fp-3Ddemo.git-3Ba-3Dblob-3Bf-3Dheat_ONAP_onap-5Fopenstack.env-3Bh-3D6a1593f5e4cf456b5d86d5464dd0faec59ad3e04-3Bhb-3Dmaster=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=ebJjFMpXijqZjbZCcbF7yJIq2ES6jM0Q-DEcP-qjjeI=BJeF7_UwemlpNjCMJLUT9IUdZIOq2ALvTH2onbhnbXA=JHOnPuz3djXfYQlmehGJh-W9I9JCnbnBJXw0ugnRwqw=>
> 2: https://github.com/docker/compose/issues/4610
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_docker_compose_issues_4610=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=ebJjFMpXijqZjbZCcbF7yJIq2ES6jM0Q-DEcP-qjjeI=BJeF7_UwemlpNjCMJLUT9IUdZIOq2ALvTH2onbhnbXA=em85m8g16dKcs1Gfh1FGI8qnDYePkQGQOf0M54VgtO4=>
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Failed demo install using "openstack vanilla" heat template

[Michael Still]

Ahhh, I see now that this is https://jira.onap.org/browse/PORTAL-138.

Michael

On Tue, Oct 31, 2017 at 11:59 AM, Michael Still <mi...@stillhq.com> wrote:

> Hi,
>
> I am using the openstack vanilla heat templates [1] to bring up an ONAP
> demo stack using Vexxhost. The stack comes up just fine, but the portal
> doesn't appear to install correctly. When I run the portal_install.sh
> script manually, I get the following errors:
>
> -
>
> + /opt/docker/docker-compose down
>
> ERROR: The Compose file './docker-compose.yml' is invalid because:
>
> Unsupported config option for services.portal-db: 'healthcheck'
>
> services.portal-wms.depends_on contains an invalid type, it should be an
> array
>
> services.portal-apps.depends_on contains an invalid type, it should be an
> array
>
> + /opt/docker/docker-compose up -d
>
> ERROR: The Compose file './docker-compose.yml' is invalid because:
>
> Unsupported config option for services.portal-db: 'healthcheck'
>
> services.portal-wms.depends_on contains an invalid type, it should be an
> array
>
> services.portal-apps.depends_on contains an invalid type, it should be an
> array
>
> -
>
> This docker bug [2] implies that I should specify version 2.1 of docker
> compose for the portal, but that's already done. However, using version
> 1.16.1 of docker-compose instead of 1.9 seems to fix the problem.
>
> Is anyone else seeing these errors? Is the openstack vanilla heat template
> known to be currently working, or am I doing something weird?
>
> Thanks heaps,
> Michael
>
>
>
> 1: Specifically https://gerrit.onap.org/r/gitweb?p=demo.git;
> a=blob;f=heat/ONAP/onap_openstack.env;h=6a1593f5e4cf456b5d86d5464dd0fa
> ec59ad3e04;hb=master
> 2: https://github.com/docker/compose/issues/4610
>
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss