Re: [OpenStack-Infra] [openstack-dev] [devstack] Devstack plugins and gate testing

2015-01-13 Thread Deepak Shetty 
On Tue, Jan 13, 2015 at 4:54 AM, Ian Wienand  wrote:

> Hi,
>
> With [1] merged, we now have people working on creating external
> plugins for devstack.
>

The devstack plugin concept seems logical and useful to me.

GlusterFS Cinder CI is probably the first one implementing the plugin.
See https://review.openstack.org/#/c/146822/




>
> I worry about use of arbitrary external locations as plugins for gate
> jobs.  If a plugin is hosted externally (github, bitbucket, etc) we
> are introducing a whole host of problems when it is used as a gate
> job.  Lack of CI testing for proposed changes, uptime of the remote
> end, ability to accept contributions, lack of administrative access
> and consequent ability to recover from bad merges are a few.
>

+1

One suggestion. The doc for creating a new project at stackforge (
http://docs.openstack.org/infra/manual/creators.html )
is for a full blown community project, there are few stuff that can be
skipped/ignored for the devstack-plugin case.

Would it be a good idea to take that doc and trim it to have just enuf
details that apply for creating a new devstack-plugin project ?


>
> I would propose we agree that plugins used for gate testing should be
> hosted in stackforge unless there are very compelling reasons
> otherwise.
>
> To that end, I've proposed [2] as some concrete wording.  If we agree,
> I could add some sort of lint for this to project-config testing.
>

+1

thanx,
deepak


>
> Thanks,
>
> -i
>
> [1] https://review.openstack.org/#/c/142805/ (Implement devstack external
> plugins)
> [2] https://review.openstack.org/#/c/146679/ (Document use of plugins for
> gate jobs)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Stackforge projects: "Manila Image Project" and licensing considerations

2015-01-13 Thread Stefano Maffulli 
On Tue, 2015-01-13 at 18:28 +, Csaba Henk wrote:
> What we are puzzled on is the license. This is something we have to
> figure out before we think of setting up the project. In general it's
> understood that Apache License (v2) is preferred. Question:
> is that a strict requirement on Stackforge or just a suggestion?

As fungi said, there are no strong requirements for Stackforge. 

On Tue, 2015-01-13 at 14:15 -0500, Doug Hellmann wrote:
> The foundation does have some rules that apply to official projects, 
> though

I believe those rules, in practice, apply only to things (for lack of a
better word) that intend to use an OpenStack trademark. The trademark
rules are hopefully going to get more clear as DefCore makes more
progress.

> - Lot of related previous art are GPL/LGPL licensed in entirety or
>   partially so we have to know if can use them.

I have the impression there are some OpenStack repositories already
incorporating LGPL software. IIRC there was a thread on legal-discuss
about this. 

> - Note that the image project is different from standard Openstack
>   related projects because it's a "meta-tool", like a compiler:
>   you don't deploy it on site, what you deploy is it's outcome
>   (a VM image).

This makes me thing that it's not a service with a public API, or is it?
In other words, do you think that DefCore will consider this
project/meta-tool as a factor to decide if a cloud (distribution) is
compatible with another? If the answer is not or unlikely then I'd not
worry too much about the 'openstack officiality' of this project.

> - AFAIU #1: the VM image (the output of the tool) is considered to be
>   a distribution of all the sofware contained in it, which means that
>   an image builder has to comply with licensing of these software
>   individually, and patches that are applied on the sources might be
>   constrained in terms of licensing (if the source is covered by a
>   copyleft license). So it's not feasible to have a pure 
>   APLv2 image builder anyway. What licensing of the image builder
>   itself (ie. not the patches) has an impact on is the "scaffolding"
>   bundled with the image (init scripts, etc).

this is complicated :) If I understood you correctly, you're wrong here:
whatever license you pick for your meta-tool, the license of its output
(the distribution) won't be affected by it. The image builder can safely
ignore the license of the individual packages put in the distribution
(especially if those images are not going to be distributed --use vs
distribution). I don't understand the sentence:

> [the image builder] has to comply with licensing of [...] patches that
> are applied on the sources

Which sources? What patches is the image builder going to apply, to
which package? 

It may make sense to review how copyright works with GNU Compiler
Collection (gcc), if you haven't read that recently. GCC is distributed
with strong copyleft and yet it's used to build very proprietary
executables. So, it's not true that if you license the
manila-image-builder you can only build 'free as in freedom'
distributions. The license of a compiler doesn't 'transfer' over to its
output. 

Even if the builder tool puts something of itself into its output (like
it copies init-scripts from itself into the image), there is an argument
that the output can still be *not* a derivative. The FSF has an article
about this case, written to explain GNU bison's behaviour:
http://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForNF

> - AFAIU #2: the above concerns the one who would like to use and customize
>   the image builder; regarding the end user who just receives and deploys 
>   the image, and applies changes/updates to it from the distributor
>   of the image (if there is such a feature), the distributor is free
>   to specify the terms of usage, as long as the image is made of open
>   source software.

I'm afraid I can't understand this part. I guess you'll have to provide
more details and examples of how the tool is supposed to work, what
packages it will collect and distribute from whom to whom.

The key element to understand which license "transfers" to other
software is to find the answer to the question: is this thing a
derivative of this other thing? and ask the question iteratively going
upstream, from the final output (the image built) all the way up to its
individual pieces. 

HTH
IAmNotALawyerThisIsNotALegalAdvice

/stef


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] [Jenkins gate failure] Can not find any error for my patch.

2015-01-13 Thread liuxinguo 
Hi all,

I have commit a bug-fix patch and it have passed the Jenkins check, but in 
Jenkins gate it failed for 
gate-cinder-python27.
I have dig into the error log but can not see anything wrong in my patch code.

Review page is:  https://review.openstack.org/#/c/143765/
And the error log for 
gate-cinder-python27
 in Jenkins gate can be seen in the attachment.

Appreciate for any input, thanks!

liu
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Stackforge projects: "Manila Image Project" and licensing considerations

2015-01-13 Thread Doug Hellmann 

> On Jan 13, 2015, at 3:05 PM, Jeremy Stanley  wrote:
> 
> On 2015-01-13 14:15:17 -0500 (-0500), Doug Hellmann wrote:
>> The foundation does have some rules that apply to official
>> projects, though.
> [...]
> 
> Yes, definitely. I interpreted the question to be specifically about
> a project which was not intending to try for official inclusion in
> OpenStack. Obviously if the project wants to target official status
> then that's a different matter license-choice-wise.

Sure, I didn’t mean to imply you thought otherwise. I just wanted to point out 
the other side of the equation.

Doug

> -- 
> Jeremy Stanley


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] [third-party] Third-Party CI Working Group meeting reminder

2015-01-13 Thread Kurt Taylor 
Hi all,

The working group meeting this week for third-party CI is Wednesday 0400
UTC in #openstack-meeting-4. That may be Tuesday evening for some, please
check your local time:

http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150114T04&p1=1440&ah=1

The agenda is here:

https://wiki.openstack.org/wiki/Meetings/ThirdParty#1.2F14.2F15_0400_UTC

Thanks!
Kurt Taylor (krtaylor)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] [infra] Infrastrucutre Puppet module split sprint, Jan 28

2015-01-13 Thread Sergey Lukjanov 
Hi openstackers,

The OpenStack Infrastructure team will be hosting a virtual sprint in
#openstack-sprint channel at Freenode for the OpenStack Infrastructure
Puppet Module split on January 28th starting at 15:00 UTC and going for 24
hours.
The main goal of this sprint is to work on splitting the rest of the
openstack-infra/system-config puppet modules by proposing new split changes
and review existing ones.

Event info:
https://wiki.openstack.org/wiki/VirtualSprints#OpenStack_puppet_module_split
Specification:
http://specs.openstack.org/openstack-infra/infra-specs/specs/puppet-modules.html
Etherpad: https://etherpad.openstack.org/p/puppet-module-split-sprint

If you're interested in participating this event, please, add yourself to
the etherpad.

Thanks.


-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Stackforge projects: "Manila Image Project" and licensing considerations

2015-01-13 Thread Jeremy Stanley 
On 2015-01-13 14:15:17 -0500 (-0500), Doug Hellmann wrote:
> The foundation does have some rules that apply to official
> projects, though.
[...]

Yes, definitely. I interpreted the question to be specifically about
a project which was not intending to try for official inclusion in
OpenStack. Obviously if the project wants to target official status
then that's a different matter license-choice-wise.
-- 
Jeremy Stanley

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Stackforge projects: "Manila Image Project" and licensing considerations

2015-01-13 Thread Doug Hellmann 

> On Jan 13, 2015, at 1:47 PM, Jeremy Stanley  wrote:
> 
> On 2015-01-13 18:28:04 + (+), Csaba Henk wrote:
> [...]
>> What we are puzzled on is the license. This is something we have
>> to figure out before we think of setting up the project. In
>> general it's understood that Apache License (v2) is preferred.
>> Question: is that a strict requirement on Stackforge or just a
>> suggestion?
> [...]
> 
> As far as I know we've no formalized license policy for StackForge
> hosting, though I think there's an assumption that it needs to be
> redistributable under an OSI/DFSG/FSF recognized license variant.
> Certainly hosting a derivative work of software which is under a
> more "copyleft" license brings those additional license terms with
> it, and seems like a reasonably pragmatic choice to me (compared
> with the alternative of reinventing the wheel entirely in a
> clean-room effort to avoid the original license terms).
> 
> http://ci.openstack.org/stackforge.html

The foundation does have some rules that apply to official projects, though. I 
don’t know how the current big-tent discussions will affect projects that are 
not using an Apache license. It has come up in the context of existing 
projects, and things that would not be expected to be included in an OpenStack 
release, but I don’t know if we’ve discussed it for projects that might want to 
be part of a release. You may want to check with the TC before choosing 
something other than Apache, just to make sure it isn’t going to turn into a 
problem for you in the future.

Doug

> 
> -- 
> Jeremy Stanley
> 
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Stackforge projects: "Manila Image Project" and licensing considerations

2015-01-13 Thread Jeremy Stanley 
On 2015-01-13 18:28:04 + (+), Csaba Henk wrote:
[...]
> What we are puzzled on is the license. This is something we have
> to figure out before we think of setting up the project. In
> general it's understood that Apache License (v2) is preferred.
> Question: is that a strict requirement on Stackforge or just a
> suggestion?
[...]

As far as I know we've no formalized license policy for StackForge
hosting, though I think there's an assumption that it needs to be
redistributable under an OSI/DFSG/FSF recognized license variant.
Certainly hosting a derivative work of software which is under a
more "copyleft" license brings those additional license terms with
it, and seems like a reasonably pragmatic choice to me (compared
with the alternative of reinventing the wheel entirely in a
clean-room effort to avoid the original license terms).

http://ci.openstack.org/stackforge.html

-- 
Jeremy Stanley

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] Stackforge projects: "Manila Image Project" and licensing considerations

2015-01-13 Thread Csaba Henk 
Hi,

I hope I'm addressing the right list -- if not, please point
me where it's appropriate.

We (Manila developers) plan to start a new side-project that would
be hosted on Stackforge. It's tentatively named "Manila Image Project",
although it would not necessarily be Manila specific.

It's aim is to provide infrastructure for building custom VM images.

So far so good.

What we are puzzled on is the license. This is something we have to
figure out before we think of setting up the project. In general it's
understood that Apache License (v2) is preferred. Question:
is that a strict requirement on Stackforge or just a suggestion?

- Lot of related previous art are GPL/LGPL licensed in entirety or
  partially so we have to know if can use them.

- Note that the image project is different from standard Openstack
  related projects because it's a "meta-tool", like a compiler:
  you don't deploy it on site, what you deploy is it's outcome
  (a VM image).

- AFAIU #1: the VM image (the output of the tool) is considered to be
  a distribution of all the sofware contained in it, which means that
  an image builder has to comply with licensing of these software
  individually, and patches that are applied on the sources might be
  constrained in terms of licensing (if the source is covered by a
  copyleft license). So it's not feasible to have a pure 
  APLv2 image builder anyway. What licensing of the image builder
  itself (ie. not the patches) has an impact on is the "scaffolding"
  bundled with the image (init scripts, etc).

- AFAIU #2: the above concerns the one who would like to use and customize
  the image builder; regarding the end user who just receives and deploys 
  the image, and applies changes/updates to it from the distributor
  of the image (if there is such a feature), the distributor is free
  to specify the terms of usage, as long as the image is made of open
  source software.

Please correct / clarify / debunk / confirm my ideas above, and
explain what is implied wrt. / required for eligibility of Stackforge
hosting.

Thanks,
Csaba


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [Support] Problems installing zuul for jenkins-gerrit gateway (Jenkins does not run jobs)

2015-01-13 Thread florian.schmidt.wel...@t-online.de 
Hello together,
 
sorry, that a gave no feedback :/
 
I finally found alittle issue, i think, i forgot to install/start zuul-merger, which seems to be a necessary part when running zuul as a gateway between gerrit and jenkins. So, the actual status quo is quite the same with the difference, that jenkins now adds the build jobs with all zuul parameters, but doesn't execute them, e.g. for the test project "jenkins" a build is planned, but not executed with the message: "waiting for next available executor", but there are 2 free executors on the master (and the only) node and the test job is the only scheduled one, so there seems to be another problem. On the other hand: Jobs triggered witht he jenkins plugin gerrit trigger get's executed immediately on the same host, same configuration (but gerrit trigger instead of gearman/zuul).
 
Any suggestions? :)
 
Freundliche GrüßeFlorian Schmidt 
 
 
-Original-Nachricht-
Betreff: Re: [OpenStack-Infra] [Support] Problems installing zuul for jenkins-gerrit gateway (Jenkins does not run jobs)
Datum: Wed, 24 Dec 2014 12:24:20 +0100
Von: "Florian Schmidt" 
An: "'Dmitry Teselkin'" 
 
 
 


Hi,
 
about the „Not permitted“ errors see my last E-Mail :) 
 
workers give me 2 (Jenkins-related) workers, “nodeName_exec-1” and “nodeName_exec-2” (I configured my Jenkins master to be able to build two jobs at one time). Both workers have all Jenkins jobs (including Jenkins-test) with a “build:” prefix (full name for Jenkins-test: “build:Jenkins-test”).
 
And status has all jobs prefixed with build:, too.
 
Von: Dmitry Teselkin [mailto:dtesel...@mirantis.com] Gesendet: Mittwoch, 24. Dezember 2014 12:15An: Florian SchmidtCc: Abhishek Shrivastava; openstack-infra@lists.openstack.orgBetreff: Re: [OpenStack-Infra] [Support] Problems installing zuul for jenkins-gerrit gateway (Jenkins does not run jobs)
 




Hi,

Could you run command 'workers' instead of 'status' against zuul and check if your jenkins job is there?

This morning I had similar issue with 'queued' jobs in zuul, and I found that although the jobs were in output from 'status' command, they weren't be in 'workers'.

And it looks like I was wrong about permissions for 'jenkins-ci' user. This user is for communications with gerrit, AFAIK.


 

On Wed, Dec 24, 2014 at 2:07 PM, Florian Schmidt  wrote:



Hi,
 
big thanks for your help! If you (or any other) need more information about something, please just ask :)
 
Kind regards,
Florian
 
Von: Abhishek Shrivastava [mailto:abhis...@cloudbyte.com] Gesendet: Mittwoch, 24. Dezember 2014 06:09An: Florian Schmidt; openstack-infra@lists.openstack.org


Betreff: Re: [OpenStack-Infra] [Support] Problems installing zuul for jenkins-gerrit gateway (Jenkins does not run jobs)




 

Hi,

 


Thanks for the information, I'll follow as you did and will come back to you as soon as I find the solution.


 

On Wed, Dec 24, 2014 at 2:54 AM, Florian Schmidt  wrote:



Hi,
 
thanks again! I’m not sure, if the document/script helps me, because i don’t want to install an external testing for openstack. Maybe this was not “clear”, but I want to use zuul as the bridge between my own gerrit and my own Jenkins installation (without openstack or any other upstream projects).
 
Nevertheless, I think I checked the settings, which are set by puppet (as good as I can without much puppet knowledge) and can’t find any difference :/
 
Kind regards and merry Christmas!
Florian
 
Von: Abhishek Shrivastava [mailto:abhis...@cloudbyte.com] Gesendet: Dienstag, 23. Dezember 2014 10:53An: Florian SchmidtBetreff: Re: [OpenStack-Infra] [Support] Problems installing zuul for jenkins-gerrit gateway (Jenkins does not run jobs)


 

Hi Florian,

 


Thanks for this article, but since we haven't got any issues like yours in our setup, therefore I am sending you one automated procedure document for setting up the CI environment that we are following. I hope it can help. 

 

On Tue, Dec 23, 2014 at 3:00 PM, Florian Schmidt  wrote:



Hello,


 


thanks for your answer. For Jenkins i used this wiki article to install it on Ubuntu server [1] and added Jobs via the Jenkins web frontend (if you need the parameter for the test job, i can attach it, but not now, cause i'm in a train :/)


 


In order to install zuul i downloaded the gearman plugin from openstack's git and build it with marven (clean install), uploaded the resulting plugin binary to jenkins (again via the web frontned), test the connection in the settings (works) and enabled gearman.


 


[1] https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Ubuntu


 


If you have further questions, i'm happy to answer :)


 


Kind regards,


Florian


 


Gesendet mit meinem HTC



 

- Reply message -Von: "Abhishek Shrivastava" An: "Florian Schmidt" ,