Re: [onap-discuss] running run-clm on all repos immediately without waiting for weekly sunday build - to fix stale nexus-iq reports

[Andrew Grimberg]

On 11/09/2018 04:40 PM, Michael O'Brien wrote:
> Team,
> 
>    Noticed some of the clm reports are stale – not reflecting current
> state of dependency issues.
> 
>    This is usually fixed by the magic word “run-clm” – in a current merge.
> 
>    Issue is how do I kick of builds in all the repos without having to
> hunt down the last commit for each repo – or without having to use
> gerrit to run Jenkins jobs.
> 
>    /michael

Greetings Michael,

The run-clm comment causes Jenkins to run against the latest tip of the
branch that it is triggered on. That means that _any_ merged change in a
repository that gets the comment will trigger the job. You don't have to
figure out the latest one and leave it on that.

As to how do you kick off builds on all repos without touching Gerrit.
You can't. What you _can_ do though, is for each repository that you
care about (and we really, really don't want you just triggering this on
all repos at once!) is do a local script that iterates over the repos
and posts a comment on them.

Something along the lines of (note this isn't tested, I'm just writing
it off the top of my head)

--[cut]--
myuid=
mygerrit=gerrit.onap.org

for i in ${REPOS}
do
  pushd ${i}
  git fetch origin
  TIP=$(git rev-parse origin/master)
  ssh -p 29418 ${myuid}@${mygerrit} gerrit review ${TIP} \
--message 'run-clm'
  popd
done
--[cut]--

That should iterate over all of the repos you care about, fetch the
origin (but not apply it to your current branch!) get the tip of the
master branch and leave a comment of 'run-clm' on it thereby triggering
Jenkins to run.

As I said, please do not do this against _all_ the repos at one time.
While we have a lot of capacity, doing something like that could easily
block actual work that needs to happen.

-Andy-

-- 
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation


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

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



signature.asc
Description: OpenPGP digital signature

Re: [onap-discuss] Unable to push patch to gerrit

[Andrew Grimberg]

This looks like you may have something misconfigured for your origin
somehow.

You should be ending up with a URL that is:

https://gerrit.onap.org/r/tools/hooks/commit-msg

Note the inclusion of the /r/ before tools in the path?

You can manually do what git review is trying to do for the hook by
doing the following from the cloned repo root:

--[cut]--
mkdir -p .git/hooks
wget https://gerrit.onap.org/r/tools/hooks/commit-msg -O
.git/hooks/commit-msg
chmod +x .git/hooks/commit-msg
--[/cut]--

On 11/08/2018 12:36 AM, Ying, Ruoyu wrote:
> Hi all,
> 
>  
> 
> I tried to push a patch to the gerrit repo, but it always shows error
> like this:
> 
> 
> ruoyu@ruoyu-dev-nuc:~/optf/osdf$ git review -R
> 
> Problems encountered installing commit-msg hook
> 
> The following command failed with exit code 104
> 
>     "GET https://gerrit.onap.org/tools/hooks/commit-msg;
> 
> ---
> 
> 
> 
> 
> 
> 
> 
> Error 404 
> 
> 
> 
> 
> 
> HTTP ERROR: 404
> 
> Problem accessing /tools/hooks/commit-msg. Reason:
> 
>     Not Found
> 
> Powered by Jetty://
> 
> 
> 
> 
> 
>  
> 
> Anyone knows how to solve the problem?
> 
> Thanks.
> 
>  
> 
> Best Regards,
> 
> Ruoyu
> 
> 

-- 
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation


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

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



signature.asc
Description: OpenPGP digital signature

Re: [onap-discuss] what does CLM stand for - as a jenkins job

[Andrew Grimberg]

On 08/02/2018 02:09 PM, Michael O'Brien wrote:
> Weird question on my part – part of narrowing down jars are pushed to
> nexus.onap.org – which occurs on merges via the *-master-merge-java job
> that kicks in
> 
>  
> 
> CLM job stands for ?
Greetings Michael,

Not so weird actually. CLM == Component Lifecycle Management (or
Manager) which is the previous name of Nexus IQ. Unfortunately Sonatype
decided to rebrand it and confuse the name "nexus" with both the
artifact storage system and the scanning tool. We've never updated
things to use a newer name because of that muddiness, but it does start
making people ask "What does CLM stand for?" ;)

-Andy-

-- 
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation


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

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



signature.asc
Description: OpenPGP digital signature

Re: [onap-discuss] [ONAP Helpdesk #57562] Jira and Gerrit integration not reliable

[Andrew Grimberg via RT]

On 06/21/2018 02:04 PM, rx1...@att.com via RT wrote:
> Dear Helpdesk,
> 
> Can you tell me why Jira sometimes shows the Gerrit submission  and
> sometimes not. I have not been able to identify a pattern to this.
> It seems to randomly work. This is a real productivity issue when we
> can't reliably depend on Jira to show us the linked Gerrit submission
> and we have to hunt around for things in Gerrit.
> 
> Thanks, Randa

Greetings Randa,

The integration is working. The issue is that the plugin maintains a
cache of changes that it's aware of. If at anytime you are feeling that
there is something that isn't being shown then to the right of the
Gerrit header there is a pull down (down arrow) that you can toggle
between the view of the types of issues. Whenever this is done it will
_force_ the plugin to invalidate the cache and recheck for changes that
meet the linking criteria.

There is no configuration for the plugin that we can set to avoid this.
The only configuration we have is to point the plugin at a single Gerrit
instance and set the search query that is used to find linked issues.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



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

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



bint05F23q9cu.bin
Description: application/rt-original-message

Re: [onap-discuss] Is Nexus2 legacy?

[Andrew Grimberg]

On 05/03/2018 01:52 AM, Jaroslav Safka wrote:
> Hi all,
> 
> I have a question regarding nexus 2 and nexus 3. Is the nexus 2 still
> required, when we have the nexus 3?
> 
> Are there any missing features in nexus 3?
> 
> Thanks and have a nice day :)

Greetings Jaroslav,

Nexus 2 is still required by our environment. The reason being that
Nexus 3 still does not provide any staging capabilities for Maven artifacts.

Additionally, we heavily leverage the fact that Nexus 2 writes artifacts
out to the standard filesystem whereas Nexus 3 only writes them out to a
blob store requiring rebuilding files on access by accessing an internal
H2 database as well as combining several files together.

Our leveraging of the filesystem configuration of Nexus 2 is used by our
log shipping routines as well as any javadoc sites that projects produce.

As such, if you look at most any of the CI setups that LF has put
together for any projects you will find a Nexus 2 in play. Nexus 3 shows
up if Docker or PyPi come into the picture.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] staging nexus repo

[Andrew Grimberg]

On 02/23/2018 11:35 AM, HERNANDEZ-HERRERO, JORGE wrote:
> Hello,
> 
> May be I missed communication, but if could you share some advice.
> 
> I noticed that from 2/8,  the staging repo, does not contain the daily
> release build artifacts
> (https://nexus.onap.org/content/repositories/staging/
> 
> The daily release staging builds are deployed instead to another
> somewhat more obscure repo(s?) such as
>  https://nexus.onap.org/content/repositories/autorelease-40840/
> .
> 
> Has the usage of https://nexus.onap.org/content/repositories/staging/
> for daily released artifacts been purposely stopped?
> 
> Thank you,
> Jorge

Greetings Jorge,

The staging artifacts have always been deployed to a repository titled
autorelease- (or something similar if they have a different staging
profile). The use of the staging meta-repository was always seen as a
best effort sort of repository. Unfortunately, due to sever limitations
with how the staging subsystem of Nexus operates it was starting to
cause more and more problems for the system. As such, our forced hack to
make it operate more like a SNAPSHOT repository was disabled at the same
time that staging repositories were removed from the automatic
repository resolution in our builds (~1.5 months before Amsterdam released).

We will not be re-enabling that hack as it caused serious problem with
the system with how many staging repositories we operate.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [ONAP Helpdesk #50852] RE: maven artifacts

[Andrew Grimberg via RT]

On 01/09/2018 06:34 AM, Gary Wu via RT wrote:
> 
> Tue Jan 09 09:34:10 2018: Request 50852 was acted upon.
>  Transaction: Ticket created by gary.i...@huawei.com
>Queue: ONAP Helpdesk
>  Subject: RE: [onap-discuss] maven artifacts
>Owner: Nobody
>   Requestors: gary.i...@huawei.com
>   Status: new
>  Ticket https://rt.linuxfoundation.org/Ticket/Display.html?id=50852 >
> 
> 
> I’m not sure why the 1.1.0-SNAPSHOT versions disappeared again.  I wonder if 
> something is wrong with Nexus.
>
> Helpdesk, can you help?  1.1.0-SNAPSHOT used to exist here, but it has since 
> disappeared: 
> https://nexus.onap.org/content/repositories/snapshots/org/onap/multicloud/openstack/multicloud-openstack-newton/
> 
> Also, there are occasions where the merge job seems to have created 
> 1.1.0-SNAPSHOT but then it’s nowhere to be found:
> https://jenkins.onap.org/view/multicloud/job/multicloud-openstack-master-newton-merge-java/57/console
> 
> Thanks,
> Gary

Nothing is wrong with Nexus. There is a 1.1.0 release of this artifact
in the system [0] Nexus auto-purges SNAPSHOT copies of released
artifacts as any further development _must_ end up on a new version
since you can't release new copies of the same version. There is a grace
period of 14 days that a SNAPSHOT version will continue to exist at the
same time that there is a release version. But in this case we're way,
way, way past that window since the release version of this happened in
the middle of November (November 16, 2017 to be specific).

If you end up generating a new SNAPSHOT artifact at a version in this
state it will exist for a very, very short amount of time until the
Nexus artifact reaper comes through which happens once a day.

-Andy-

[0]
https://nexus.onap.org/content/repositories/releases/org/onap/multicloud/openstack/multicloud-openstack-newton/1.1.0/

> 
> From: Morales, Victor [mailto:victor.mora...@intel.com]
> Sent: Monday, January 08, 2018 9:43 AM
> To: Gary Wu ; Yang, Bin (Wind River) 
> ; Guo, Ruijing ; 
> onap-discuss@lists.onap.org
> Subject: Re: [onap-discuss] maven artifacts
> 
> Hey Gary,
> 
> We’re still having issues to deploy the 1.1.0-SNAPSHOT version for 
> multicloud-openstack-newton artifact [1].  The –merge-java job looks like was 
> successfully executed [2] when the version was bumped [3] but there is no 
> artifact placed for that specific version, as consequence other jobs are 
> failing [4].  I’m not sure if the deployment process needs to be done 
> separately (per subproject) [5] given that the parent pom.xml contains the 
> reference of every subproject[6]
> 
> Regards/Saludos
> Victor Morales
> 
> [1] 
> https://nexus.onap.org/content/repositories/snapshots/org/onap/multicloud/openstack/multicloud-openstack-newton/
> [2] 
> https://logs.onap.org/production/vex-yul-ecomp-jenkins-1/multicloud-openstack-master-newton-merge-java/55/console.log.gz
> [3] https://gerrit.onap.org/r/#/c/24617/
> [4] 
> https://jenkins.onap.org/job/multicloud-openstack-master-ocata-verify-java/65/
> [5] 
> https://git.onap.org/ci-management/tree/jjb/multicloud/multicloud-openstack.yaml
> [6] https://git.onap.org/multicloud/openstack/tree/pom.xml#n37
> 
> From: 
> >
>  on behalf of Gary Wu >
> Date: Thursday, December 21, 2017 at 9:58 AM
> To: "Yang, Bin (Wind River)" 
> >, "Guo, Ruijing" 
> >, 
> "onap-discuss@lists.onap.org" 
> >
> Subject: Re: [onap-discuss] maven artifacts
> 
> I’m not sure why it didn’t work before, but I just re-ran that job and now 
> the artifact is there.
> 
> Thanks,
> Gary
> 
> From: Yang, Bin [mailto:bin.y...@windriver.com]
> Sent: Wednesday, December 20, 2017 6:51 PM
> To: Gary Wu >; GUO, RUIJING 
> >; 
> onap-discuss@lists.onap.org
> Subject: RE: [onap-discuss] maven artifacts
> 
> Hi Gary,
> 
>The -merge-java job seems working well, but the snaphot 
> artifacts is nowhere to find on nexus.onap.org. Could you help look into this 
> log to find out any clue ?
> 
> https://jenkins.onap.org/view/multicloud/job/multicloud-openstack-master-newton-merge-java/lastBuild/console
> 
> Thanks.
> 
> Best Regards,
> Bin Yang,Solution Readiness Team,Wind River
> Direct +86,10,84777126Mobile +86,13811391682Fax +86,10,64398189
> Skype: yangbincs993
> 
> From: Gary Wu [mailto:gary.i...@huawei.com]
> Sent: Wednesday, December 20, 2017 3:40 PM
> To: GUO, RUIJING; 
> onap-discuss@lists.onap.org
> Cc: Yang, Bin
> 

Re: [onap-discuss] [onap-tsc] [Gerrit] Commit message restriction

[Andrew Grimberg]

On 11/28/2017 11:07 PM, Vitaliy Emporopulo wrote:
> Hi,
> 
>  
> 
> As a committer I’d say it should be enforced. Committers have tons of
> other work to do that cannot be automated.
> 
>  
> 
> On the other hand, the problem with revert Alexis has pointed out must
> be solved. Probably by automatically trimming the original header, so
> that together with the word “revert: “ it’s no more than 50 characters
> long. This way the message will still contain enough info to understand
> which commit was reverted.
> 
>  
> 
> There doesn’t seem to be a suitable hook
>  for that, but probably the commit
> hook can be modified to check if a commit message starts with “revert: “.

This isn't hook that we can modify how it's checking, it's a gerrit
built in that is being used. The only option we have related to the
subject line is a maximum line length.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [ONAP Helpdesk #48276] Huge Jenkins queue

[Andrew Grimberg via RT]

On Thu Nov 16 10:46:39 2017, agrimberg wrote:
> On Thu Nov 16 10:07:50 2017, jeremyphelps wrote:
> > Hi Gary,
> > We have identified the issue.  There will be a pause in the Jenkins
> > queue momentarily to sort the situation.
> > Jeremy
> >
> > On Thu Nov 16 10:01:54 2017, jeremyphelps wrote:
> > > Hi Gary,
> > > We are currently set at 40.  I'm seeing if we can increase now.
> > > Jeremy
> > >
> > > On Thu Nov 16 09:52:53 2017, gary.i...@huawei.com wrote:
> > > > Hi helpdesk,
> > > >
> > > > Currently there are almost 100 Jenkins jobs backed up as we're
> > > > ramping
> > > > up for the release.  Any way we can temporarily increase the
> > > > number
> > > > of
> > > > Jenkins slaves to help out?
> > > >
> > > > Thanks,
> > > > Gary
> 
> Please note, we are still actively working this issue. Jenkins is
> currently in shutdown mode as we are evaluating if we need to actually
> give Jenkins a restart to get an error we're seeing the logs which is
> related to it bringing build instances online to clear.
> 
> -Andy-

Greetings folks,

After poking the system some more and giving Jenkins a restart we've cleared up 
the problem with the build instances not properly connecting. We have also 
temporarily increased the maximum number of instance from 40 to 60 to better 
speed along clearing the queue.

-Andy-

-- 
Andrew Grimberg
The Linux Foundation
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [ONAP Helpdesk #48276] Huge Jenkins queue

[Andrew Grimberg via RT]

On Thu Nov 16 10:07:50 2017, jeremyphelps wrote:
> Hi Gary,
> We have identified the issue.  There will be a pause in the Jenkins
> queue momentarily to sort the situation.
> Jeremy
> 
> On Thu Nov 16 10:01:54 2017, jeremyphelps wrote:
> > Hi Gary,
> > We are currently set at 40.  I'm seeing if we can increase now.
> > Jeremy
> >
> > On Thu Nov 16 09:52:53 2017, gary.i...@huawei.com wrote:
> > > Hi helpdesk,
> > >
> > > Currently there are almost 100 Jenkins jobs backed up as we're
> > > ramping
> > > up for the release.  Any way we can temporarily increase the number
> > > of
> > > Jenkins slaves to help out?
> > >
> > > Thanks,
> > > Gary

Please note, we are still actively working this issue. Jenkins is currently in 
shutdown mode as we are evaluating if we need to actually give Jenkins a 
restart to get an error we're seeing the logs which is related to it bringing 
build instances online to clear.

-Andy-

-- 
Andrew Grimberg
The Linux Foundation
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [ONAP] [releng] add rest doc check on jenkins gating

[Andrew Grimberg]

Greetings Morgan,

First, as ONAP is an open source project, please ask your questions out
in the public. Closed door discussions do not help the community. As
such, I've added the ONAP discuss list.

Second, global-jjb is an also open source and anyone can contribute to
it. The project generally sees a release every 2 weeks, though we do
sometimes do off cycle point releases to fix bugs. You just need to
contribute in the LF gerrit [0] as global-jjb is shared by all of the
projects that engage LF Release Engineering services.

-Andy-

[0]
https://gerrit.linuxfoundation.org/infra/#/admin/projects/releng/global-jjb

On 11/13/2017 05:46 AM, morgan.richo...@orange.com wrote:
> Hi
> 
> do you think it would be possible to add a documentation gating on the
> generic macro?
> 
> the idea would be for any repo, if "docs" sub-directory exists, to
> perform a doc8 check
> 
> it will avoid hundreds of Warnings and Errors and provide a better
> overall quality
> Each project will remain responsible of the integrity of its rst files,
> the doc project cannot be responsible for the rst of all the projects
> 
> My idea would be to add "ci-management-doc" in {project}-verify-jjb as
> we have a check unicode
> (https://git.onap.org/ci-management/tree/jjb/ci-management/ci-management.yaml)
> 
> ci-management-doc will be declared in
> https://git.onap.org/ci-management/tree/jjb/global-macros.yaml
> 
> - builder:
>     name: ci-management-check-doc
>     builders:
>   - shell: |
>   $WORKSPACE/scripts/check-code.sh
> 
> and check-code will perform a simple doc8 check (see
> https://git.opnfv.org/opnfvdocs/tree/scripts/docs-build.sh or create
> virtual env and run a tox -edocs on each repo on patch submission
> jenkins jobs env is not always easy to setup, is there any sandbox to
> test jenkins jobs in ONAP?
> 
> if errors => jenkins vote -1
> at the beginning some projects may have to fix their doc errors...before
> getting a +1 from jenkins, but the sooner the better...
> most of the projects are already clean on this aspect
> 
> in // I strongly suggest to add the -W option in the docs project when
> generating sphinx documentation. -W means Warnings = Errors, jenkins
> will vote -1 if there is 1 Warning. This option is adopted in OpenStack
> and some OPNFV projects.
> As for the project gating, at the beginning some people may complain but
> at the end it is better for the community...
> 
> what is your view?
> Who is contributing to the generic jobs/macros? Shall I suggest a patch
> (as said I am blind to test..so I assume ci-management team (Andrew?)
> would have a better view on how to do this)
> shall I open a ticket in helpdesk?
> 
> Thanks
> 
> /Morgan
> 
> 
> _
> 
> 
> 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.
> 

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Question on creating APPC release

[Andrew Grimberg]

On 11/08/2017 11:23 AM, MAHER, RANDA wrote:
> Hello all…
> 
> Since this is just a question and not an issue, I’m not going the help
> desk ticket route…Hope you can provide guidance on how we should proceed
> with below issue…Thanks, Randa
> 
>  
> 
> APPC has many ccsdk artifacts as dependencies in our project. Right now,
> we are using a release version (not snapshot) of ccsdk, but this version
> is pulled from the staging nexus repository since the artifacts are not
> yet available in the release nexus. We are wondering if we should wait
> for ccsdk to release those artifacts into the release nexus before we
> build and release our release version ?
> 
> We also use ccsdk's docker image as a base to our docker image, so this
> would be a similar issue. Should we wait for ccsdk to release their
> final docker image before we create our release docker image?
@Note I'm adding in the discuss list as this is relevant information for
the entire community.

Greetings Randa,

If you depend on that project then you should be waiting until they have
released for your release.

In general a project should not be depending on unreleased artifacts
from an upstream project for their release. It's bad practice and may
get you into trouble in the future if you're not careful. Always
depending on only released artifacts will help greatly.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [integration] RE: Accessing VMs on CSIT

[Andrew Grimberg]

There is no shell access available to any instances in the environment.

If you need to do any sort of troubleshooting but don't want to log out
to the archives, I suggest utilizing the sandbox and creating jobs that
output any extra diagnostics you want.

-Andy-

On 09/28/2017 08:18 AM, Gary Wu wrote:
> Not that I’m aware of, but you can log a request with LF and see what
> they say. 
> 
>  
> 
> If you need things checked, usually you’ll need to log a request with LF
> helpdesk to get them to do that for you.  The alternative is to collect
> more log information.  In your scripts, you can put things into
> $WORKSPACE/archives/, and those files will be collected into the log
> directory on nexus for that job. 
> 
>  
> 
> Thanks,
> 
> Gary
> 
>  
> 
> *From:* RAJU, CHINNAPPA [mailto:cr7...@att.com]
> *Sent:* Thursday, September 28, 2017 8:06 AM
> *To:* Gary Wu 
> *Cc:* HERNANDEZ-HERRERO, JORGE ; DRAGOSH, PAM
> ; HOTZE, BECKY L ;
> ABDULMANNAN, MOHAMMED 
> *Subject:* Accessing VMs on CSIT
> 
>  
> 
> Hi Gary,
> 
>  
> 
> I know the VMs change every time a build is triggered. But in case we
> want to logon to a VM before it is destroyed and see what is going on,
> is there a way?
> 
>  
> 
>  
> 
> Thanks & Regards,
> 
> Chinnappa Raju
> 
> SENIOR QUALITY TESTER
> 
> ECOMP Open Source Automation
> 
>  
> 
> 
> 
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
> 

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] jenkins job settings read-only access - getting 504 timeout

[Andrew Grimberg]

On 09/28/2017 07:19 AM, Michael O'Brien wrote:
> DevOps team,
> 
>    Hi, noticed that we can’t view the settings on Jenkins jobs – is
> there a way to get read-only access – looks like a file-system-level
> access issue as the page content comes up empty  – just curious
> 
>    Thank you
> 
>    /Michael
> 
>    Example
> 
> https://jenkins.onap.org/view/so/job/so-master-docker-version-java-daily/
> 
> view-configuration
> 
> https://jenkins.onap.org/view/so/job/so-master-docker-version-java-daily/configure
> 
> build | provide configuration files | view selected file
> 
> https://jenkins.onap.org/?id=global-settings

Greetings Michael,

We do not allow non-admins to view managed files. The reason is that
there are environment passwords that are not public in some of those
files. As such, allowing public access would be a security leak.

> https://jenkins.onap.org/jobConfigHistory/
> 
> Show system configs only
> 

Jenkins system history is not available to non-admins for similar
reasons as the managed files.

> 
> Show created jobs only
> 
> Show deleted jobs only
> 
> Show all configs 
> 
> No permission to view system changes
> 
> Clicking on any above
> 
> *504 Gateway Time-out*

Requesting the history on all jobs that you've got access to can be a
lot of data. Jenkins itself, particularly if under load, may not be able
to render the full data set. If you're interested in the historical
changes related to a specific job it's better to look at the history via
that particular job itself.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] gerrit archive fetch

[Andrew Grimberg]

On 09/27/2017 09:09 AM, DeWayne Filppi wrote:
> Is there a way to "curl" archives from gerrit urls?  Similar to github
> (which basically adds 'archive' to the path).

Greetings DeWayne,

Gerrit itself doesn't support archiving of the git repositories. That
being said, if you browse the project listing you'll see a 'gitweb' link
which brings you to a gitweb interface which does support that.

Additionally, when looking at any change in Gerrit you should also see
gitweb links against the change itself as well as the parent, which will
link you into the appropriate location in the gitweb view.

There is also a cgit view of the repositories available @
https://git.onap.org. Archiving is also available there.

Finally, we do have a work item on our plate to get all of the live
repos mirroring into GitHub. It's not been a big priority though as it's
a lot of busy work that burns time better spent in community support at
present.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [ONAP Helpdesk #44125] [integration] Independent project artifact release process

[Andrew Grimberg via RT]

On Wed Aug 16 15:26:15 2017, gary.i...@huawei.com wrote:
> Hi Andy,
> 
> Thanks for your feedback.  I would like to do a trial run of this
> process with oparent and document the instructions.
> 
> To confirm, is the preferred way to do a staging build via the "-
> release-version-java-daily" jobs?  Do we currently have any
> documentation on how to setup/use the staging build jobs?  For
> example, I think it requires a version.properties file to be defined
> in the repo; not sure if there are other requirements.

Greetings Gary,

Just circling back on this. I'm going to direct this at [0]

> For the GPG signed tag, do we have any recommended instructions for
> the project committers/PTLs to do so themselves, or should we assume
> that LFRE will take care of this for the time being?

At present LFRE will take care of this, as I'm sure you're aware of with your 
recent releases of oparent.

[0] https://wiki.onap.org/display/DW/Independent+Versioning+and+Release+Process

-- 
Andrew Grimberg
The Linux Foundation
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [ONAP Helpdesk #45935] Jenkins Sandbox Setup Issue

[Andrew Grimberg via RT]

On Tue Sep 19 12:59:55 2017, jwagantall wrote:
> - You will need to comment this lines in jjb/global-jjb/jjb/lf-
> macros.yaml and jjb/global-macros.yaml
>   - openstack:
>   single-use: true

The above should not be done. Even when using the sandbox you want your 
instance to be single use, otherwise work that you're testing in the sandbox 
can impact other folks testing work.

-Andy-

-- 
Andrew Grimberg
The Linux Foundation
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [integration][ci-management] How to retrigger jenkins jobs without resubmitting patch

[Andrew Grimberg]

On 08/17/2017 04:52 PM, Lu, Lianhao wrote:
> Hi guys,
> 
> I’m just want to if there is a way to retrigger a Jenkins job (e.g.
> xx-yy-zz-verity-python) without proposing a new patch set?
> 
> Best Regards,
> 
> -Lianhao

Greetings Lianhao,

To retrigger the verify job, just leave a comment on the open Gerrit of
'recheck' without the quotes. It will cause Jenkins to re-run any
validation jobs it has that would be triggered by a new patch.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Upcoming ONAP Nexus3 outage 2017-08-17 @ 16:00 - 17:00 PDT (23:00 - 00:00 UTC)

[Andrew Grimberg]

This work has now been completed.

-Andy-

On 08/17/2017 03:55 PM, Andrew Grimberg wrote:
> This work will be starting shortly.
> 
> -Andy-
> 
> On 08/15/2017 12:40 PM, Andrew Grimberg wrote:
>> What: The Linux Foundation will be performing a maintenance update on
>> the ONAP Nexus3 server located at https://nexus3.onap.org
>>
>> When: Thursday August 17, 2017 @ 16:00 - 17:00 PDT (23:00 - 00:00 UTC,
>> 07:00 - 08:00 CST)
>>
>> Why: There are several outstanding updates that the Nexus3 system is
>> currently needing. The most pressing of which is supposed to fix a build
>> in space management job that has been failing for some time and the
>> system is currently critically low on disk space
>>
>> Impact: Jenkins will be placed into shutdown mode 30 minutes before the
>> outage to prevent too many jobs from failing during the needed
>> maintenance. Nexus3 itself will become unavailable during the update and
>> restart of the service meaning that docker images will not be available
>> during the duration of the restart.
>>
>> Notices will be posted at the start and end to the mailing lists, #onap
>> on Freenode IRC as well as status being kept up to date on
>> https://status.linuxfoundation.org/
>>
>> -Andy-
>>
> 

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Upcoming ONAP Nexus3 outage 2017-08-17 @ 16:00 - 17:00 PDT (23:00 - 00:00 UTC)

[Andrew Grimberg]

This work will be starting shortly.

-Andy-

On 08/15/2017 12:40 PM, Andrew Grimberg wrote:
> What: The Linux Foundation will be performing a maintenance update on
> the ONAP Nexus3 server located at https://nexus3.onap.org
> 
> When: Thursday August 17, 2017 @ 16:00 - 17:00 PDT (23:00 - 00:00 UTC,
> 07:00 - 08:00 CST)
> 
> Why: There are several outstanding updates that the Nexus3 system is
> currently needing. The most pressing of which is supposed to fix a build
> in space management job that has been failing for some time and the
> system is currently critically low on disk space
> 
> Impact: Jenkins will be placed into shutdown mode 30 minutes before the
> outage to prevent too many jobs from failing during the needed
> maintenance. Nexus3 itself will become unavailable during the update and
> restart of the service meaning that docker images will not be available
> during the duration of the restart.
> 
> Notices will be posted at the start and end to the mailing lists, #onap
> on Freenode IRC as well as status being kept up to date on
> https://status.linuxfoundation.org/
> 
> -Andy-
> 

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] How to get Access Rights : GIT Repo

[Andrew Grimberg]

Note: Dropping the original message since it was all graphics. As an FYI
doing that instead of copy paste of terminal information makes it a lot
harder to do good replies.

Neeraj, the error that is in your issue is stating that you are getting
a connection time out to port 29418 which is the SSH port for Gerrit.
This error is generally indicative of a corporate network that is
blocking outbound traffic on that port. To work around this you will
need to use the authenticated http configuration.

To use this method of working with Gerrit you will have to have Gerrit
generate an HTTP password for you to use as it won't use your user
account password.

To get the password that you need you'll need to log into the Gerrit UI,
select your user name from the upper right -> Settings -> HTTP Password

Press the Generate Password button and then copy the password that is
displayed.

See this [0] page for more detailed instructions related to both SSH and
HTTP configuration.

-Andy-

[0] https://wiki.onap.org/display/DW/Configuring+Gerrit

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [ONAP Helpdesk #44125] Independent project artifact release process

[Andrew Grimberg via RT]

Greetings Gary,

On 08/16/2017 11:34 AM, Gary Wu via RT wrote:

> Resending since I didn't get a ticket number back for some reason last time.

Not certain why you didn't. The original ticket, which I've merged this
into is 44125

> From: Gary Wu
> Sent: Wednesday, August 09, 2017 12:37 PM
> To: 'helpd...@onap.org' 
> Cc: onap-discuss@lists.onap.org
> Subject: [integration] Independent project artifact release process
> 
> Hi helpdesk,
> 
> ONAP is moving toward a model where each project/repo will be
> releasing its own artifacts and versions, and cross-repo dependencies
> are on release artifacts only (i.e. no SNAPSHOT/staging dependencies).
> Integration will be piloting this with oparent and clamp repos to work
> out all the kinks.
> 
> To that end, we will need a clear process for individual projects to
> version bump and release their own artifacts.
> 
> ONAP currently has Jenkins job definitions that will deploy release
> artifact candidates to staging. What seems to be missing is a way for a
> project to pick a candidate from staging and formally release it into
> the Releases repo. Does this process exist? If so, can you point me to
> some documentation on how this process works? If not, can you share your
> thoughts on how we can best implement this last step?

The closest we currently have is the process that OpenDaylight has been
operating with for their odlparent project which as of the current
release cycle has broken off to doing independent releases of it's one.
In fact during the Nitrogen cycle it's already had at least 4 releases
that I'm aware of!

The current process that has been in use in ODL by odlparent is detailed
in the lead mail in this [0] mailing list thread.

LF is working on ways that the we can grant more of the process control
to the projects themselves but we don't currently have everything needed
for it just yet.

To get the heart of your request the current way for an ONAP project to
formally do a release at present would be as follows:

1) A staging build has happened. In the job logs there will be a notice
as to what the staging repository that was created is. This needs to be
captured by a project committer / PTL that will be requesting a release

2) Any testing that needs to be performed against the artifacts is
performed.

3) A helpdesk ticket is opened requesting that LF Release Engineering
perform a signing and release operation on the target staging repository

4) LFRE will pull the artifacts, GPG sign them, push a secondary staging
repository with the signatures and then perform a release operation
inside nexus which will cause it to transition both the requested
staging repository and the signature repository to copy into the
releases repository and then delete the staging repositories.

5) A GPG signed tag needs to be placed on the commit by either LFRE or
preferably the PTL or a committer of the project with the release version

For docker images, we don't currently have as much automated tooling in
place but the basic flow is:

1) Identify the STAGING docker slice that is to be released

2) Open a ticket with LF to release the specific docker

3) LFRE will pull the docker image and retag it into the nexus docker
releases repository and push

4) The image should also then be pushed to dockerhub

Eventually, this will all get fully automated in some fashion with the
correct checks and balances in place for restricting who can do what.
Once we have a good automation flow in place then it will probably be a
matter of an authorized party submitting a gerrit change to a special
repository / specially formatted comment to trigger Jenkins to perform
operations on behalf of folks.

-Andy-

[0] https://lists.opendaylight.org/pipermail/dev/2017-August/003990.html

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation




binrzPHcH0pRW.bin
Description: application/rt-original-message
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] Upcoming ONAP Nexus3 outage 2017-08-17 @ 16:00 - 17:00 PDT (23:00 - 00:00 UTC)

[Andrew Grimberg]

What: The Linux Foundation will be performing a maintenance update on
the ONAP Nexus3 server located at https://nexus3.onap.org

When: Thursday August 17, 2017 @ 16:00 - 17:00 PDT (23:00 - 00:00 UTC,
07:00 - 08:00 CST)

Why: There are several outstanding updates that the Nexus3 system is
currently needing. The most pressing of which is supposed to fix a build
in space management job that has been failing for some time and the
system is currently critically low on disk space

Impact: Jenkins will be placed into shutdown mode 30 minutes before the
outage to prevent too many jobs from failing during the needed
maintenance. Nexus3 itself will become unavailable during the update and
restart of the service meaning that docker images will not be available
during the duration of the restart.

Notices will be posted at the start and end to the mailing lists, #onap
on Freenode IRC as well as status being kept up to date on
https://status.linuxfoundation.org/

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [linuxfoundation.org #44094] Re: [linuxfoundation.org #44094] RE: [ONAP Helpdesk #44094] 答复: Re: 答复: [integration] RE: About CI job Script for python project in ONAP

[Andrew Grimberg via RT]

Gary's changes have been merged in and the redis image has been built.
I've added a new minion template to allow the image to come online.

-Andy-

On 08/10/2017 09:55 AM, Gary Wu via RT wrote:
> 
> Sorry about that.  I’ve submitted a fix into ci-management: 
> https://gerrit.onap.org/r/#/c/7229/
> 
> Thanks,
> Gary
> 
> From: fu.jin...@zte.com.cn [mailto:fu.jin...@zte.com.cn]
> Sent: Wednesday, August 09, 2017 5:54 PM
> To: onap-helpd...@rt.linuxfoundation.org
> Cc: zhang.maope...@zte.com.cn; Gary Wu ; 
> onap-discuss@lists.onap.org
> Subject: 答复: [ONAP Helpdesk #44094] 答复: Re: [onap-discuss]答复: [integration] 
> RE: About CI job Script for python project in ONAP
> 
> 
> Hi Jess,
> 
> I think Gary's script has some mistakes, you can see the following log
> 
> 18:13:06 openstack: mv: cannot stat '/tmp/redis-4.0.1/redis-server': No 
> such file or directory
> 
> Gary's Scripts(Path of redis-server and redis.conf are wrong)
> 
># 2. set conf file and init script
> 
> mv /tmp/redis-4.0.1/redis-server /etc/init.d/redis-server
> 
> chmod +x /etc/init.d/redis-server
> 
> mv /tmp/redis-4.0.1/redis.conf /etc/redis.conf
> 
> 
> 
> Thanks,
> 
> Jinhua
> 
> 
> 
> 
> 
> 
> 原始邮件
> 发件人： 
> >;
> 收件人：张茂鹏10030173;
> 抄送人：傅锦华10108953; >; 
> >;
> 日 期 ：2017年08月10日 07:01
> 主 题 ：[ONAP Helpdesk #44094] 答复: Re: [onap-discuss]答复: [integration] RE: About 
> CI job Script for python project in ONAP
> 
> 
> Dear Maopeng,
> 
> I am currently working on this.
> Looking at the current failures found here:
> https://jenkins.onap.org/job/ci-management-merge-packer-ubuntu-16.04-redis/1/console
> 
> Will let you know once I get this resolved
> 
> Thanks!
> Jess
> 
> 
> 
> 
> 

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation




bin0XKCAnBr98.bin
Description: application/rt-original-message
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [onap-tsc] Code Review: how to avoid long delay to review

[Andrew Grimberg]

On 08/10/2017 10:31 AM, DRAGOSH, PAMELA L (PAM) wrote:
> My understanding was that when someone submits code for review, that
> committers automatically get email notification for it and also
> automatically get added to the list of reviewers. However, this has been
> inconsistent.

The ONAP Gerrit is not configured in any way to automatically add
reviewers to a change.

There are two plugins available for doing this sort of work:

reviewers - which won't work because we use and LDAP backend for
accounts and it requires the defined auto-reviewers to be local accounts
and groups

maintainers - which the fd.io community, and Cisco in explicit,
developed for their Gerrit which utilizes a MAINTAINERS file in the repo
for managing the automatic reviewer setup. I don't recommend this one
(yet) as they're still working out the bugs in it ;)

If you've been getting added "automatically" then it would be from
someone adding you as a reviewer. If, however, you leave a review then
you're automatically added as a watcher for any future changes.

> Being a committer, I have noticed that sometimes I am added as a
> reviewer automatically, while other times I am not. Not sure why not. I
> do utilize the “watch” projects functionality so that I don’t miss
> something because of this inconsistency.

I recommend that committers aways setup watches on projects that they're
a commit for. I, and the more active LF RE's for ONAP do this for the
ci-management project.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [integration]Jenkins Build Failure

[Andrew Grimberg]

On 08/09/2017 07:10 AM, Guangrong Fu wrote:
> Hi integration team,
> 
> Could you please have a look at the jenkins job below? They have been
> failing for a week.
> 
> https://jenkins.onap.org/view/holmes/job/holmes-dsa-master-clm/1/console
> For this job, there's one fatal error:
> ​ ​
> [FATAL] Non-readable POM /w/workspace/holmes-dsa-master-clm/pom.xml:
> /w/workspace/holmes-dsa-master-clm/pom.xml (No such file or
> directory). I have no idea on how to fix it.

This failed because there was no merged code in the repository when the
weekly job fired. It should resolve itself when the job automatically
runs again.

> https://jenkins.onap.org/view/holmes/job/holmes-engine-management-master-release-version-java-daily/8/console
> For this one, I don't
> ​even ​
> know the actual reason because I can not find any obvious error in the log.

--[cut]--
11:56:21 [EnvInject] - [ERROR] - The given properties file path
'version.properties' doesn't exist.
11:56:21 [EnvInject] - [ERROR] - Missing file path was resolved from
pattern 'version.properties' .
11:56:21 [EnvInject] - [ERROR] - Problems occurs on injecting env vars
as a build step: java.io.IOException: remote file operation failed:
/w/workspace/holmes-engine-management-master-release-version-java-daily
at hudson.remoting.Channel@7b9420fc:ubuntu1604-basebuild-4c-4g-6462:
java.io.IOException: The given properties file path 'version.properties'
doesn't exist.
--[/cut]--

You're missing a version.properties file which is required by the the
job the job template.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [linuxfoundation.org #44058] Re: [ONAP Helpdesk #44058] RE: RE: RE: Re: 答复: [integration] RE: About CI job Script for python project in ONAP

[Andrew Grimberg via RT]

On 08/08/2017 07:17 AM, Gary Wu via RT wrote:
> Hi helpdesk,
> 
> Can you help?  It seems that the redis minion is unavailable in Jenkins.
> 
> Thanks,
> Gary

While the template has been merged, the ci-management job set that
creates the packer image still needs to be updated. After the job is
updated and the image built there is a manual process that LF Release
Engineering must do to update any Jenkins minion definitions to make use
of the new images. This is true for updates to current images as well.

This means that there are still several steps needed to be performed
before the image is available.

-Andy-

> From: fu.jin...@zte.com.cn [mailto:fu.jin...@zte.com.cn]
> Sent: Monday, August 07, 2017 8:01 PM
> To: Gary Wu 
> Cc: onap-discuss@lists.onap.org
> Subject: 答复: RE: RE: Re:[onap-discuss] 答复: [integration] RE: About CI job 
> Script for python project in ONAP
> 
> 
> Hi Gary,
> 
> I found that your commit for redis install in jenkins env has merged, and I 
> modify the job node to ‘ubuntu1604-redis-4c-4g’,
> 
> but jenkins shows that node  ‘ubuntu1604-redis-4c-4g’ can not be found, can 
> you check it again?
> 
> Thanks,
> 
> Jinhua

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation




binOoKTu5QowL.bin
Description: application/rt-original-message
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Versioning for Amsterdam

[Andrew Grimberg]

It's the same process we would follow for a single simultaneous release.
The difference is that each component would be (and presently ONAP does
this) producing their own staging repository.

So, the release is then a matter of identifying which repositories are
part of the release and doing the artifact signing on those and releases
in nexus to the release repository.

The Simultaneous Release would be more of an identifying what components
are actually part of the tested SR and potentially some final single
produced downloadable object that doesn't do the build, but just
incorporates the individually released components.

LF Release Engineering (RelEng) has been fixing up our release scripts
dealing with this sort of thing. They are now part of the lftools python
project [0] [1] (installable via PyPi). ODL itself has started down the
road of individual components being able to release off sync from each
other with the current Nitrogen release cycle. The odlparent project has
already had at least 3 different releases in the middle of the cycle! We
expect that the next project up the stack (yangtools) will do that with
the Oxygen release as they transition to SemVer which really is a
requirement for this to work correctly.

We have additional work coming that will allow us to automate the
artifact signing and will therefore allow us to move more of the release
processes into the hands of the community itself instead of relying on
RelEng for so much of it.

-Andy-

[0] https://gerrit.linuxfoundation.org/infra/#/admin/projects/releng/lftools
[1] https://github.com/lfit/releng-lftools

On 07/20/2017 10:41 AM, Gary Wu wrote:
> Hi Andy,
> 
> Can you chime in on how the release process would work (vis-à-vis use of 
> staging repos, artifact signings, etc.) if ONAP decides to have independent 
> version numbers and possibly independent release cycles for each module?
> 
> Thanks,
> Gary
> 
> 
> -Original Message-
> From: onap-discuss-boun...@lists.onap.org 
> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Gino Fraboni
> Sent: Thursday, July 20, 2017 7:04 AM
> To: SPATSCHECK, OLIVER (OLIVER) ; Yunxia Chen 
> 
> Cc: onap-discuss@lists.onap.org
> Subject: Re: [onap-discuss] Versioning for Amsterdam
> 
> 
> I'll throw in my +1 for version 2 as well.
> And semantic versioning makes complete sense to me.
> 
> 
> Gino Fraboni
> Senior Software Developer
> Amdocs Data Experience
> 
> 
> 
> A Platinum member of ONAP  
> Read the latest on Amdocs.com and the Amdocs blog network – and follow us on 
> Facebook, Twitter, LinkedIn and YouTube.
> 
> 
> 
> -Original Message-
> From: onap-discuss-boun...@lists.onap.org 
> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of SPATSCHECK, OLIVER 
> (OLIVER)
> Sent: Thursday, July 20, 2017 9:54 AM
> To: Yunxia Chen 
> Cc: onap-discuss@lists.onap.org
> Subject: Re: [onap-discuss] Versioning for Amsterdam
> 
> 
> I agree that we should do 3.) independent of 1.) and 2.) ( Again I don’t 
> think there has been a final decision but I din’t hear any opposition to 3. 
> so far).
> 
> As for:
> 
> " AAI version 2.0.3, AAF version 1.0.8, Clamp version 0.9.0.”
> 
> I think that’s actually a good thing. 
> 
> First we are using 3rd party software of different versions anyway. All those 
> components depend on often hundreds of jar files which have all kind of 
> version numbers and version number schemes. So if we are going with 2.) we 
> are treating other components not differently as we would treat external 
> components from a build perspective.
> 
> Also above would more honestly represent maturity. E.g. if we are introducing 
> a new component and ONAP itself is in release 10.X.X should the “beta” 
> version of that new component have a 10.X.X release number of a 0.X.X release 
> number. Giving it a 10.X.X release number as the first release is very 
> misleading… . Also easier for CICD if we ever decided to go that route. 
> 
> As for the question if there would be one version per project or repo I would 
> really leave this up to the projects to work out. If we can handle one per 
> project the build infrastructure will also be able to handle one per repo.
> 
> I like Pam’s suggestion. Let’s set up some time to close on this next week at 
> the virtual dev meeting. 
> 
> Gildas can you set up the discussion as part of the release planing?
> 
> Thx
> 
> Oliver
> 
>> On Jul 19, 2017, at 7:27 PM  EDT, Yunxia Chen  wrote:
>>
>> Option 3 is an alternative as option 1. I +1 for option 1 or option 3 from 
>> Integration point of view and end user point of view.
>>  
>> I understand that the “freedom” on each project with its own versioning. As 
>> stated in Gildas’s email, currently we have 20+ projects which will 
>> participate the Arsterdam simultaneous release, it will be very hard for us 
>> to test all those combinations and maintain that mapping.
>>  
>> 

Re: [onap-discuss] Getting Release Engineering support

[Andrew Grimberg]

helpd...@onap.org gets redirected to
onap-helpd...@rt.linuxfoundation.org on the backend. They're one and the
same location. The first is just easier for most folks to remember ;)

-Andy-

On 07/19/2017 01:34 PM, MAHER, RANDA wrote:
> Hi Andrew,
> 
> The email I had for requesting support was 
> onap-helpd...@rt.linuxfoundation.org 
> Should this be retired in favor of helpd...@onap.org  or do both work?
> 
> Thanks, Randa 
> 
> -Original Message-
> From: onap-discuss-boun...@lists.onap.org 
> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Andrew Grimberg
> Sent: Wednesday, July 19, 2017 10:57 AM
> To: onap-discuss@lists.onap.org
> Subject: [onap-discuss] Getting Release Engineering support
> 
> Greetings folks,
> 
> I've been seeing a large uptick in unicast support requests directly to 
> myself or myself and other LF Release Engineers.
> 
> As an reminder, the LF Release Engineering team does not work on support 
> requests that are directed to our personal / corporate email. Support 
> requests _must_ be directed at our helpdesk ticketing system by sending them 
> to helpd...@onap.org
> 
> If we feel that the request / issue doesn't warrant being in a ticket we'll 
> pull the discussion offline from the ticketing system, but that is where you 
> should be starting for most things.
> 
> -Andy-
> 
> --
> Andrew J Grimberg
> Lead, IT Release Engineering
> The Linux Foundation
> 

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] Gerrit survey

[Andrew Grimberg]

Greetings folks,

A survey was sent to the Gerrit mailing list yesterday soliciting
feedback from admins and users of Gerrit. If you want to possibly
influence changes to Gerrit here's your chance :)

It will take about 15 minutes to do.

https://google.qualtrics.com/jfe/form/SV_0JKI9MBgY4eY4x7

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] Getting Release Engineering support

[Andrew Grimberg]

Greetings folks,

I've been seeing a large uptick in unicast support requests directly to
myself or myself and other LF Release Engineers.

As an reminder, the LF Release Engineering team does not work on support
requests that are directed to our personal / corporate email. Support
requests _must_ be directed at our helpdesk ticketing system by sending
them to helpd...@onap.org

If we feel that the request / issue doesn't warrant being in a ticket
we'll pull the discussion offline from the ticketing system, but that is
where you should be starting for most things.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Are draft gerrit public?

[Andrew Grimberg]

On 07/16/2017 06:15 PM, Alexis de Talhouët wrote:
> Hello,
> 
> I was surprised to see one of my draft on SDC being publicly
> available. I thought those were private, or I haven't catch the notice
> that this project is making them visible.
> Is that true for all projects? Or just for SDC?
> Also, if there is any mail mentioning this transition, could you link it
> as I must have missed it.

Greetings Alexis,

The TSC voted to convert all drafts to public during the last meeting.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] [releng] Change to Jenkins Job Builder

[Andrew Grimberg]

Greetings folks,

In an effort to improve inefficiencies across our managed projects The
Linux Foundation Release Engineering (LF RelEng) team has been working
on a couple of projects. These projects are global-jjb [0] and lftools
[1]. They are mirrored on GitHub at [2] and [3].

I'm making this announcement in part because Jeremy has just completed a
migration of the ci-management verify and merge jobs to using our new
global versions of them.

What does this mean for you? It means the following, if you do any work
on job updates and wish to test locally you will need to now do a
submodule init in any local clone of ci-management. The following would
be what you do on a clean clone:

--[cut]--
LFID=yourLFID
git clone ssh://${LFID}@gerrit.onap.org:29418/ci-management.git
cd ci-management
git submodule update --init --recursive
--[/cut]--

If you've already got a clone then do the following:

--[cut]--
git checkout master
git pull
git submodule update --init --recursive
--[/cut]--

You will find that we use the GitHub mirror for the submodule, which is
intentional as it will allow us to do work on the LF Gerrit system
without affecting production systems :)

In the coming weeks we'll be going through and modifying current
templates to use some of our global macros instead of local ones as well
as seeing where we can transition current jobs in use to templates in
our global repo.

-Andy-

[0]
https://gerrit.linuxfoundation.org/infra/#/admin/projects/releng/global-jjb
[1] https://gerrit.linuxfoundation.org/infra/#/admin/projects/releng/lftools
[2] https://github.com/lfit/releng-global-jjb
[3] https://github.com/lfit/releng-lftools

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Upcoming system restarts

[Andrew Grimberg]

This work has now been completed.

-Andy-

On 06/20/2017 03:45 PM, Andrew Grimberg wrote:
> This work will be starting shortly. It is estimated to take about 30
> minutes.
> 
> -Andy-
> 
> On 06/20/2017 08:41 AM, Andrew Grimberg wrote:
>> The Linux Foundation has been made aware of some extremely high priority
>> security updates that will be getting released within the next 24 - 48
>> hours. These updates are so critical that we will be taking immediate
>> outage windows to apply them when they become available.
>>
>> This update will cause rolling restarts of the infrastructure as we do
>> system reboots.
>>
>> An additional notice will go out prior to our starting this work and
>> another when we complete it.
>>
>> -Andy-
>>
> 

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Upcoming system restarts

[Andrew Grimberg]

This work will be starting shortly. It is estimated to take about 30
minutes.

-Andy-

On 06/20/2017 08:41 AM, Andrew Grimberg wrote:
> The Linux Foundation has been made aware of some extremely high priority
> security updates that will be getting released within the next 24 - 48
> hours. These updates are so critical that we will be taking immediate
> outage windows to apply them when they become available.
> 
> This update will cause rolling restarts of the infrastructure as we do
> system reboots.
> 
> An additional notice will go out prior to our starting this work and
> another when we complete it.
> 
> -Andy-
> 

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] Upcoming system restarts

[Andrew Grimberg]

The Linux Foundation has been made aware of some extremely high priority
security updates that will be getting released within the next 24 - 48
hours. These updates are so critical that we will be taking immediate
outage windows to apply them when they become available.

This update will cause rolling restarts of the infrastructure as we do
system reboots.

An additional notice will go out prior to our starting this work and
another when we complete it.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Request Jenkins configuration extension for LF Portal

[Andrew Grimberg]

+onap-discuss

These sorts of discussions should be held in the public where everyone
can benefit.

On 06/12/2017 10:41 AM, LOTT, CHRISTOPHER M (CHRISTOPHER) wrote:
> Thanks Andrew. I cloned that project and am trying to figure it out.  Looks 
> like I could modify global-defaults.yaml (probably the wrong thing to do); 
> modify global-templates-java.yaml (in many many places); or limit the scope 
> to just the portal project (seems the best option).  So I found this file - 
> it seems to reference a variable 'portal-settings' but I cannot find where 
> that is defined, what it contains, etc.  Please advise.
> 
> 
> bd-228-251:~/git/ci-management/jjb/portal$ cat portal.yaml 
> 
> ---
> - project:
> name: portal
> project-name: 'portal'
> jobs:
>   - '{project-name}-{stream}-release-version-java-daily'
>   - '{project-name}-{stream}-stage-site-java':
>   site-pom: 'pom.xml'
>   trigger-job: '{project-name}-{stream}-release-version-java-daily'
> 
> project: 'portal'
> stream:
>   - 'master':
>   branch: 'master'
>   - 'release-1.0.0':
>   branch: 'release-1.0.0'
> mvn-settings: 'portal-settings'   <-- is this my hook 
> to make a change??

That file is non-settable by any of the projects. It's the credentials
settings file that LF provides to each project in our systems. It is
required to be "${projectrepo}-settings".

The correct thing to do is the following:

1) Determine what job(s) it is you're trying to modify
2) Determine if there are variables already being passed in that you can
modify to do what you want, if there are, then modify them in your
project definition
3) If there are not, then updating the job template to take a new
variable is something that can be done, but then all projects that are
using the template must be updated to pass a proper default so as to not
break the jobs.

-Andy-

> files: '**'
> archive-artifacts: ''
> build-node: ubuntu1604-basebuild-4c-4g
> 
> 
> 
> 
>> On Jun 12, 2017, at 12:53 PM, Andrew Grimberg 
>> <agrimb...@linuxfoundation.org> wrote:
>>
>> On 06/12/2017 09:34 AM, LOTT, CHRISTOPHER M (CHRISTOPHER) wrote:
>>> I would like to suggest a extension to the Jenkins job that builds the ONAP 
>>> Portal back-end (compiles java, yields war file).  The job is probably 
>>> "portal-master-release-version-java-daily".  I propose to add this argument 
>>> to mvn: "-Dbuild.number=${BUILD_NUMBER}".  This passes thru the build 
>>> number chosen by Jenkins so it can be used as a unique artifact identifier. 
>>>  Our POM the incorporates that detail into the manifest file so the webapp 
>>> can display a unique version number.
>>>
>>> So right now the config shows these arguments ("Goals") to mvn33:
>>>
>>> clean deploy sonar:sonar -Dsonar.host.url=${SONAR} -B 
>>> -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn
>>>
>>> I would like to extend this field to be:
>>>
>>> clean deploy sonar:sonar -Dsonar.host.url=${SONAR} -B 
>>> -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn
>>>  -Dbuild.number=${BUILD_NUMBER}
>>>
>>> Please advise how these things are handled - do I need to write a Jira 
>>> ticket?  Thanks.
>>
>> Submit a change in gerrit against the ci-management project. The jobs
>> are publicly defined and get code reviewed just like anything else.
>>
>> -Andy-
>>
>> -- 
>> Andrew J Grimberg
>> Lead, IT Release Engineering
>> The Linux Foundation
>>
> 

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Staging repo in settings.xml

[Andrew Grimberg]

On 05/25/2017 02:36 PM, Gary Wu wrote:
> That makes sense given that staging artifacts were supposed to exist
> only long enough to decide whether they're good to release or not;
> they were not meant to be used as long-lived build dependencies.
> 
> I think the right thing to do is to move away from this "build
> against staging" approach relatively soon.  Given that our formal 1st
> release is November, and assuming that the release artifact version
> will be "1.0.0", I see two options:
> 
> 1. Do not release any thing from staging right now.  Change all
> artifact versions to 1.0.0-SNAPSHOT.
> 
> 2.  For the subset of artifacts that need to be "locked down",
> actually release the staging candidates right now as 1.0.0-RC0 or
> some such.  Then change all artifact versions to 1.0.0-SNAPSHOT,
> except explicit dependencies on the released 1.0.0-RC0 artifacts
> where desired.
> 
> Any other ideas?
> 
> Do we have a full list of the artifacts that explicitly need to be
> served up from staging repos right now?  I'm hoping this list is
> relatively short.

Not something I can answer. I would hope that the seed projects can
answer that.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] Staging repo in settings.xml

[Andrew Grimberg]

On 05/24/2017 11:34 AM, SPATSCHECK, OLIVER  (OLIVER) wrote:
> 
>> On May 24, 2017, at 10:54 AM  EDT, Gary Wu 
>> wrote:
>> 
>> 3) I understand that all the staging process was meant to be
>> temporary, and to add on Gary’s last question, what is the plan
>> moving forward and how could we contribute to that effort ?
> 
> I think that’s a TSC question. We wouldn’t mind moving this to a
> formal release just because it makes it easier to deal with the code.
> However,   the current plan is to have the first formal release in
> November when the code bases have merged and not on the seed code in
> the current repos.  Assuming we stick with that plan it means we will
> stay in staging at least till November to ensure we have a working
> code base for demos etc… .

One things I'll note about the setup. Our staging repositories are
dropped after 14 days. This is a hard drop, so if artifacts that are
there need to stick around at all right now they need to be regularly
refreshed _or_ a release needs to actually happen.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] [nexus] Missing com.github.sevntu.checkstyle:sevntu-checks artifact in ONAP Nexus

[Andrew Grimberg]

First: requests to add proxies need to go to the helpdesk
(helpd...@onap.org)

Second: ONAP _already_ proxies ODL's release repository and the
odl-third-party repository. We _will not_ proxy the 'public' repo from
ODL as that's a repo group. If there is a specific repo that needs to be
proxied that we're not currently proxying then we need to know what it
is and the co-ords for adding the proxy.

You can easily see what repos are hosted or proxied by looking at
https://nexus.onap.org/#view-repositories.

Third: Third party artifacts that do not have a maven repository should
be thoroughly reviewed and assessed as to the actual need. We do not
like hosting these sorts of things because it means we have to track
upstream security announcements for such artifacts. It's far better to
convince the upstream to either get a Maven repo available for people to
utilize / proxy or to get their artifacts into Maven central.

-Andy-

On 05/19/2017 06:35 AM, ROSE, DANIEL V wrote:
> Andrew can LF add the odl repo? I don’t think we are supposed to add
> 3^rd party repos right?
> 
>  
> 
> Daniel Rose
> 
> ECOMP / ONAP
> 
> com.att.ecomp
> 
> 732-420-7308
> 
>  
> 
> *From:*onap-discuss-boun...@lists.onap.org
> [mailto:onap-discuss-boun...@lists.onap.org] *On Behalf Of *Alexis de
> Talhouët
> *Sent:* Friday, May 19, 2017 8:13 AM
> *To:* onap-discuss@lists.onap.org
> *Subject:* [onap-discuss] [nexus] Missing
> com.github.sevntu.checkstyle:sevntu-checks artifact in ONAP Nexus
> 
>  
> 
> Hello,
> 
> 
> My patches [1] are failing due to unresolved dependency: 
> 
> 
> 14:47:28 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check
> (check-license) on project dblib-features: Execution check-license of
> goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check failed:
> Plugin org.apache.maven.plugins:maven-checkstyle-plugin:2.17 or one of
> its dependencies could not be resolved: The following artifacts could
> not be resolved:
> com.github.sevntu.checkstyle:sevntu-checkstyle-maven-plugin:jar:1.21.0,
> com.github.sevntu.checkstyle:sevntu-checks:jar:1.21.0: Failure to find
> com.github.sevntu.checkstyle:sevntu-checkstyle-maven-plugin:jar:1.21.0
> in https://nexus.onap.org/content/repositories/releases/
> 
>  was
> cached in the local repository, resolution will not be reattempted until
> the update interval of releases has elapsed or updates are forced ->
> [Help 1]
> 
>  
> 
> It seems that indeed, this is not present in ONAP’s Nexus public repo.
> Indeed, this is coming from ODL, and it’s hosted in ODL’s public repo
> [2]. Can we make this available in ONAP’s third-party repo, and/or proxy
> ODL’s public's one?
> 
>  
> 
> Thanks,
> 
> Alexis
> 
>  
> 
> [1]: https://gerrit.onap.org/r/#/q/topic:features-parent\
> 
> 
> [2]: 
> https://nexus.opendaylight.org/content/repositories/public/com/github/sevntu/checkstyle/
> 
> 
>  
> 
>  
> 
> 
> 
> ___
> onap-discuss mailing list
> onap-discuss@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-discuss
> 

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Re: [onap-discuss] CI integration

[Andrew Grimberg]

On 05/04/2017 05:43 AM, Alon Strikovsky wrote:
> Guys thank you for your tips,
> 
> One important things the we are missing is the */setting.xml/* that is
> assigned to each job.
> 
> I cannot find any trace of how they are built.
> 
> Any tips ?
> 
>  
> 
> Alon

Greetings folks,

I'm attaching a copy of the content from our global-settings managed
config file. For the $project-settings files they are configured as follows:

ServerIDs:

ecomp-raw
ecomp-releases
ecomp-snapshots
ecomp-site
ecomp-staging
nexus3.onap.org:10001   -- uid: docker  / password: docker
nexus3.onap.org:10002
nexus3.onap.org:10003
nexus3.onap.org:10004

In all of the cases, except the nexus3.onap.org:10001, the user attached
is the one needed for that particular project to be able to push to our
nexus systems

The content is the default for a settings file as given by the managed
configuration provider plugin.

For the various environment variables, I suggest you look at the shipped
logs of one of the jobs. There is a build-environment-varisbles.txt.gz
file that is a dump of the final rendered environment variables.

The ones that are current pushed by jenkins as part of our global
configuration are currently:

GIT_BASE-- ssh://ecomp-jobbuil...@gerrit.onap.org:29418/$PROJECT
GIT_NO_PROJECT
JENKINS_HOSTNAME
LOGS_REPO_URL
LOGS_SERVER
NEXUSPROXY
SILO
SONAR

(The other settings you can lookup as I suggested, but since GIT_BASE
incorporates another variable it was apropos to show how it's actually
configured)

Please note that the global env vars are updated and modified as our
needs change. I know that with some of the work that LF Release
Engineering is currently doing to better align the JJB that is used by
all projects is going to mean we modify how some of these variables are
used as well as what variables are defined.

-Andy-

-- 
Andrew J Grimberg
Systems Administrator
Release Engineering Team Lead
The Linux Foundation



http://maven.apache.org/SETTINGS/1.0.0;
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd;>

  

  release-mirror
  Local Nexus mirror for builds
  ${env.NEXUSPROXY}/content/repositories/public/
  central

  

  

  releases
  

  releases
  releases
  ${env.NEXUSPROXY}/content/repositories/releases/
  
true
never
  
  
false
  

  

  

  releases
  releases
  ${env.NEXUSPROXY}/content/repositories/releases/
  
true
never
  
  
false
  

  



  staging
  

  staging
  staging
  ${env.NEXUSPROXY}/content/repositories/staging/
  
true
  
  
false
  

  



  snapshots
  

  snapshots
  snapshots
  ${env.NEXUSPROXY}/content/repositories/snapshots/
  
false
  
  
true
  

  

  

  snapshots
  snapshots
  ${env.NEXUSPROXY}/content/repositories/snapshots/
  
false
  
  
true
  

  


  

  
releases
staging
snapshots
  



signature.asc
Description: OpenPGP digital signature
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] Proposal for list split of onap-discuss

[Andrew Grimberg]

On 04/20/2017 04:05 PM, Brian Hedstrom wrote:
> I like using Slack and creating different slack channels as one option
> instead of email lists for general discussion type content. I prefer
> using the Wiki for discussions centered around artifacts as it puts the
> discussion thread at the bottom of the wiki page containing the work
> artifact.

While Slack is a wonderful tool, I'll point out that it has several
drawbacks when it comes to cross-community communication and does have
issues with how people have to be invited into the system, even if using
an 'invite-bot'. The other issue I, personally, have with it is the
account explosion you end up with if you have to deal with multiple "teams".

That all being said, there are currently two (that I know of) IRC
channels on Freenode for ONAP they're

#onap
#onap-meeting <- this one hosts a meetingbot for collaborative meeting
minute taking and is already used by the TSC for their weekly meetings

-andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: 

[onap-discuss] Proposal for list split of onap-discuss

[Andrew Grimberg]

On 04/20/2017 03:28 PM, Aimee Ukasick wrote:
> On 04/20/2017 02:44 PM, Ed Warnicke wrote:
>> Thinking outloud... it almost feels like mailing lists as a tool are no
>> longer a good fit to the need.
>>
>> Is there another tool we could consider using?
>>
> I personally like the idea of a discussion bulletin board/forum where
> developers can ask for help and discuss ideas. Late last year, OPNFV
> created a tech-discuss forum, but there has been little activity in it.
> Developers seem to prefer email and IRC. Maybe using a forum would catch
> on if the forum were created at inception instead of a couple of years
> into the life of the project.
> 
> 
> [1] https://techdiscuss.opnfv.org/

As I mentioned earlier in the thread. We've got the Questions module [0]
installed on the wiki.

It's essentially a StackOverflow style forum for Confluence. Folks just
need to start using it for it to be useful.

[0] https://wiki.onap.org/questions

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: 

[onap-discuss] Proposal for list split of onap-discuss

[Andrew Grimberg]

On 04/20/2017 09:46 AM, Ed Warnicke wrote:
> Josef,
> 
> I couldn't agree more.  Typically 'discuss' in most communities is for
> 'cross project' discussion.  Project specific converstions tend to happen on
> ${project}-dev mailers (think dcae-dev, sdnc-dev, etc).   For this to
> work, one needs projects.  Projects *need* their own space to hold
> publicly visible conversations.
> 
> I would strongly recommend *against* a single list in the long term.  It
> becomes overwhelming, and it strongly discourages folks sending email
> because the room is so big.

Our largest communities have major cross-posting problems along with new
people regularly informing us that they don't know where to send things
because of having too many lists. As such, I can't express how strongly
I recommend only breaking out a specific topic to a separate list _iff_
it proves to cause too much traffic on the general list.

As Aimee pointed out OpenStack, which is a community larger than our
largest community, doesn't do what you're talking about. They use topics
on their lists precisely to get around the mailing list explosion of a
list per project that you're suggesting.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: 

[onap-discuss] Proposal for list split of onap-discuss

[Andrew Grimberg]

On 04/20/2017 08:52 AM, Aimee Ukasick wrote:
> Andy Grimberg - do you where I create a ticket to have projects added to
> the onap-discuss top categories?

helpdesk at onap.org which is the address for any sort of infrastructure /
managed configuration changes.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: 

[onap-discuss] Proposal for list split of onap-discuss

[Andrew Grimberg]

On 04/20/2017 07:32 AM, Brijesh Khandelwal wrote:
> Basic question:
> Why no community discussion forum?
> 
> --Brijesh

We have the Questions module [0] for Confluence installed on the wiki.
This does act as a discussion forum. Admittedly, it doesn't look like
anyone is really using it yet, though there is one question sitting
there since... March?

-Andy-

[0] https://wiki.onap.org/questions

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: 

[onap-discuss] ONAP Nexus outage

[Andrew Grimberg]

On 04/18/2017 08:36 AM, Andrew Grimberg wrote:
> This morning at 09:41 ET we received an alert that the primary Nexus
> system for ONAP. This system hosts the maven repositories and
> documentation sites for ONAP projects.
> 
> We have finally determined the cause of the issue and are working on a fix.

We have a bandaid in place and the service back online. We will be
implementing a more permanent fix but that should not incur any
additional downtime.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.onap.org/pipermail/onap-discuss/attachments/20170418/b0d6670f/attachment.sig>

[onap-discuss] ONAP Nexus outage

[Andrew Grimberg]

This morning at 09:41 ET we received an alert that the primary Nexus
system for ONAP. This system hosts the maven repositories and
documentation sites for ONAP projects.

We have finally determined the cause of the issue and are working on a fix.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: 

[onap-discuss] can NOT login gerrit any more

[Andrew Grimberg]

On 03/30/2017 01:08 AM, Lu, Lianhao wrote:
> Hi guys,
> 
> I used to be able to login https://gerrit.openecomp.org  with my
> linux foundation ID. But from yesterday, I found that with the change
> to https://gerrit.onap.org , I can't access it any more.  It reports
> the following error on the web page:
> 
> Cannot assign user name "LianhaoLu" to account 629; name already in
> use.
> 
> Does anyone know how to fix this issue? Thanks!
> 
> Best Regards, -Lianhao 

Gretings Lianhao,

Could you send an email to helpdesk at openecomp.org (we haven't gotten the
helpdesk at onap.org setup yet) with your problem? One the LF engineers
will be able to help you then.

-Andy-

-- 
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: