Re: [openstack-dev] [CI][TripleO][Ironic] check-tripleo-ironic-xxx fails

2014-12-26 Thread Adam Gandelman
This is fallout from a new upstream release of pip that went out earlier in
the week.  It looks like no formal bug ever got filed, tho the same problem
discovered in devstack and trove's integration testing repository.  Added
some comments comments to the bug.

On Thu, Dec 25, 2014 at 10:59 PM, James Polley j...@jamezpolley.com wrote:

 Thanks for the alert

 The earliest failure I can see because of this is
 http://logs.openstack.org/43/141043/6/check-tripleo/check-tripleo-ironic-overcloud-precise-nonha/36c9771/

 I've raised https://bugs.launchpad.net/tripleo/+bug/1405732 and I've put
 some preliminary notes on
 https://etherpad.openstack.org/p/tripleo-ci-breakages

 On Fri, Dec 26, 2014 at 3:42 AM, ZhiQiang Fan aji.zq...@gmail.com wrote:

 check-tripleo-ironic-xxx failed because:

 rm -rf /home/jenkins/.cache/image-create/pypi/mirror/
 rm: cannot remove `/home/jenkins/.cache/image-create/pypi/mirror/':
 Permission denie

 see

 http://logs.openstack.org/37/143937/1/check-tripleo/check-tripleo-ironic-overcloud-precise-nonha/9be729b/console.html

 search on logstash.openstack.org:
 message:rm: cannot remove
 `/home/jenkins/.cache/image-create/pypi/mirror/\': Permission denied
 there are 59 hits in last 48 hours



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



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


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


Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

2014-12-26 Thread Punith S
hello,

i have setup the CI environment for our cloudbyte storage, running a master
jenkins vm and a slave node vm running devstack.

i have followed the jay's blog using asselin's scripts from github.

all i need to do is to test our cloudbyte cinder driver against the cinder
tempest suit.

currently the noop-check-communication job is coming of successfully on
openstack-dev/sandbox project

but the *dvsm full tempest *job is failing due to an error in failing to
upload the images to the glance service from swift.

how can i hack the dsvm tempest full job so that it only installs my
required services like cinder,nova,horizon etc. ?

does modifying the devstack gate scripts help ?

i'm attaching the links for the failure of dsvm-tempest-full job

devstacklog.txt - http://paste.openstack.org/show/154779/
devstack.txt.summary - http://paste.openstack.org/show/154780/

thanks




On Tue, Dec 23, 2014 at 8:46 PM, Asselin, Ramy ramy.asse...@hp.com wrote:

  You should use 14.04 for the slave. The limitation for using 12.04 is
 only for the master since zuul’s apache configuration is WIP on 14.04 [1],
 and zuul does not run on the slave.

 Ramy

 [1] https://review.openstack.org/#/c/141518/

 *From:* Punith S [mailto:punit...@cloudbyte.com]
 *Sent:* Monday, December 22, 2014 11:37 PM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help
 setting up CI



 Hi Asselin,



 i'm following your readme https://github.com/rasselin/os-ext-testing

 for setting up our cloudbyte CI on two ubuntu 12.04 VM's(master and slave)



 currently the scripts and setup went fine as followed with the document.



 now both master and slave have been connected successfully, but in order
 to run the tempest integration test against our proposed cloudbyte cinder
 driver for kilo, we need to have devstack installed in the slave.(in my
 understanding)



 but on installing the master devstack i'm getting permission issues in
 12.04 in executing ./stack.sh since master devstack suggests the 14.04 or
 13.10 ubuntu. and on contrary running install_slave.sh is failing on 13.10
 due to puppet modules on found error.



  is there a way to get this work ?



 thanks in advance



 On Mon, Dec 22, 2014 at 11:10 PM, Asselin, Ramy ramy.asse...@hp.com
 wrote:

  Eduard,



 A few items you can try:

 1.   Double-check that the job is in Jenkins

 a.   If not, then that’s the issue

 2.   Check that the processes are running correctly

 a.   ps -ef | grep zuul

i.  Should
 have 2 zuul-server  1 zuul-merger

 b.  ps -ef | grep Jenkins

i.  Should
 have 1 /usr/bin/daemon --name=jenkins  1 /usr/bin/java

 3.   In Jenkins, Manage Jenkins, Gearman Plugin Config, “Test
 Connection”

 4.   Stop and Zuul  Jenkins. Start Zuul  Jenkins

 a.   service Jenkins stop

 b.  service zuul stop

 c.   service zuul-merger stop

 d.  service Jenkins start

 e.  service zuul start

 f.service zuul-merger start



 Otherwise, I suggest you ask in #openstack-infra irc channel.



 Ramy



 *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
 *Sent:* Sunday, December 21, 2014 11:01 PM


 *To:* Asselin, Ramy
 *Cc:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help
 setting up CI



 Thanks Ramy,



 Unfortunately i don't see dsvm-tempest-full in the status output.

 Any idea how i can get it registered?



 Thanks,

 Eduard



 On Fri, Dec 19, 2014 at 9:43 PM, Asselin, Ramy ramy.asse...@hp.com
 wrote:

  Eduard,



 If you run this command, you can see which jobs are registered:

 telnet localhost 4730



 status



 There are 3 numbers per job: queued, running and workers that can run job.
 Make sure the job is listed  last ‘workers’ is non-zero.



 To run the job again without submitting a patch set, leave a “recheck”
 comment on the patch  make sure your zuul layout.yaml is configured to
 trigger off that comment. For example [1].

 Be sure to use the sandbox repository. [2]

 I’m not aware of other ways.



 Ramy



 [1]
 https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L20

 [2] https://github.com/openstack-dev/sandbox









 *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
 *Sent:* Friday, December 19, 2014 3:36 AM
 *To:* Asselin, Ramy
 *Cc:* OpenStack Development Mailing List (not for usage questions)

 *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help
 setting up CI



 Hi all,

 After a little struggle with the config scripts i managed to get a working
 setup that is able to process openstack-dev/sandbox and run
 noop-check-comunication.



 Then, i tried enabling dsvm-tempest-full job but it keeps returning
 NOT_REGISTERED



Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

2014-12-26 Thread Eduard Matei
@Asselin:
Regarding the few items you can try: i tried everything, the job still
appears NOT_REGISTERED.
I'll see next week if i can do a clean install on another jenkins master.

Thanks for your help,
Eduard

On Fri, Dec 26, 2014 at 11:23 AM, Punith S punit...@cloudbyte.com wrote:

 hello,

 i have setup the CI environment for our cloudbyte storage, running a
 master jenkins vm and a slave node vm running devstack.

 i have followed the jay's blog using asselin's scripts from github.

 all i need to do is to test our cloudbyte cinder driver against the cinder
 tempest suit.

 currently the noop-check-communication job is coming of successfully on
 openstack-dev/sandbox project

 but the *dvsm full tempest *job is failing due to an error in failing to
 upload the images to the glance service from swift.

 how can i hack the dsvm tempest full job so that it only installs my
 required services like cinder,nova,horizon etc. ?

 does modifying the devstack gate scripts help ?

 i'm attaching the links for the failure of dsvm-tempest-full job

 devstacklog.txt - http://paste.openstack.org/show/154779/
 devstack.txt.summary - http://paste.openstack.org/show/154780/

 thanks




 On Tue, Dec 23, 2014 at 8:46 PM, Asselin, Ramy ramy.asse...@hp.com
 wrote:

  You should use 14.04 for the slave. The limitation for using 12.04 is
 only for the master since zuul’s apache configuration is WIP on 14.04 [1],
 and zuul does not run on the slave.

 Ramy

 [1] https://review.openstack.org/#/c/141518/

 *From:* Punith S [mailto:punit...@cloudbyte.com]
 *Sent:* Monday, December 22, 2014 11:37 PM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need
 help setting up CI



 Hi Asselin,



 i'm following your readme https://github.com/rasselin/os-ext-testing

 for setting up our cloudbyte CI on two ubuntu 12.04 VM's(master and slave)



 currently the scripts and setup went fine as followed with the document.



 now both master and slave have been connected successfully, but in order
 to run the tempest integration test against our proposed cloudbyte cinder
 driver for kilo, we need to have devstack installed in the slave.(in my
 understanding)



 but on installing the master devstack i'm getting permission issues in
 12.04 in executing ./stack.sh since master devstack suggests the 14.04 or
 13.10 ubuntu. and on contrary running install_slave.sh is failing on 13.10
 due to puppet modules on found error.



  is there a way to get this work ?



 thanks in advance



 On Mon, Dec 22, 2014 at 11:10 PM, Asselin, Ramy ramy.asse...@hp.com
 wrote:

  Eduard,



 A few items you can try:

 1.   Double-check that the job is in Jenkins

 a.   If not, then that’s the issue

 2.   Check that the processes are running correctly

 a.   ps -ef | grep zuul

i.  Should
 have 2 zuul-server  1 zuul-merger

 b.  ps -ef | grep Jenkins

i.  Should
 have 1 /usr/bin/daemon --name=jenkins  1 /usr/bin/java

 3.   In Jenkins, Manage Jenkins, Gearman Plugin Config, “Test
 Connection”

 4.   Stop and Zuul  Jenkins. Start Zuul  Jenkins

 a.   service Jenkins stop

 b.  service zuul stop

 c.   service zuul-merger stop

 d.  service Jenkins start

 e.  service zuul start

 f.service zuul-merger start



 Otherwise, I suggest you ask in #openstack-infra irc channel.



 Ramy



 *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
 *Sent:* Sunday, December 21, 2014 11:01 PM


 *To:* Asselin, Ramy
 *Cc:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need
 help setting up CI



 Thanks Ramy,



 Unfortunately i don't see dsvm-tempest-full in the status output.

 Any idea how i can get it registered?



 Thanks,

 Eduard



 On Fri, Dec 19, 2014 at 9:43 PM, Asselin, Ramy ramy.asse...@hp.com
 wrote:

  Eduard,



 If you run this command, you can see which jobs are registered:

 telnet localhost 4730



 status



 There are 3 numbers per job: queued, running and workers that can run
 job. Make sure the job is listed  last ‘workers’ is non-zero.



 To run the job again without submitting a patch set, leave a “recheck”
 comment on the patch  make sure your zuul layout.yaml is configured to
 trigger off that comment. For example [1].

 Be sure to use the sandbox repository. [2]

 I’m not aware of other ways.



 Ramy



 [1]
 https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L20

 [2] https://github.com/openstack-dev/sandbox









 *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
 *Sent:* Friday, December 19, 2014 3:36 AM
 *To:* Asselin, Ramy
 *Cc:* OpenStack Development Mailing List (not for usage questions)

 *Subject:* Re: [openstack-dev] [OpenStack-Infra] 

Re: [openstack-dev] [Openstack] Need help in validating CPU Pinning feature

2014-12-26 Thread joejiang
Hi Srinivasa,


This section is related to cpu affinity in instance xml file. 
 vcpu placement='static' cpuset='1-12'4/vcpu


Regards,
Joe Chiang




At 2014-12-26 12:25:29, Srinivasa Rao Ragolu srag...@mvista.com wrote:

Hi All,


I have been working on CPU Pinning feature validation.


I could able set vcpu_pin_set config in nova.conf and could able to see cpupin 
set in guest xml and working fine while launching.


Please let me know how can I set cputune: vcpupin in guest xml?


Or 


Any documents refer to validate cpu pinning use cases.


Thanks,
Srinivas.___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [CI][TripleO][Ironic] check-tripleo-ironic-xxx fails

2014-12-26 Thread Denis Makogon
On Fri, Dec 26, 2014 at 11:01 AM, Adam Gandelman ad...@ubuntu.com wrote:

 This is fallout from a new upstream release of pip that went out earlier
 in the week.  It looks like no formal bug ever got filed, tho the same
 problem discovered in devstack and trove's integration testing repository.
 Added some comments comments to the bug.


Proper solution was merged into devstack (see [1]) and proposed for
trove-integration (see [2]). So, it seems that we've faced with same
problem across multiple projects that are relaying on pip.


[1] https://review.openstack.org/#/c/143501
[2] https://review.openstack.org/#/c/143746/

Kind regards,
Denis M.


 On Thu, Dec 25, 2014 at 10:59 PM, James Polley j...@jamezpolley.com wrote:

 Thanks for the alert

 The earliest failure I can see because of this is
 http://logs.openstack.org/43/141043/6/check-tripleo/check-tripleo-ironic-overcloud-precise-nonha/36c9771/

 I've raised https://bugs.launchpad.net/tripleo/+bug/1405732 and I've put
 some preliminary notes on
 https://etherpad.openstack.org/p/tripleo-ci-breakages

 On Fri, Dec 26, 2014 at 3:42 AM, ZhiQiang Fan aji.zq...@gmail.com
 wrote:

 check-tripleo-ironic-xxx failed because:

 rm -rf /home/jenkins/.cache/image-create/pypi/mirror/
 rm: cannot remove `/home/jenkins/.cache/image-create/pypi/mirror/':
 Permission denie

 see

 http://logs.openstack.org/37/143937/1/check-tripleo/check-tripleo-ironic-overcloud-precise-nonha/9be729b/console.html

 search on logstash.openstack.org:
 message:rm: cannot remove
 `/home/jenkins/.cache/image-create/pypi/mirror/\': Permission denied
 there are 59 hits in last 48 hours



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



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



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


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


Re: [openstack-dev] [Openstack] Need help in validating CPU Pinning feature

2014-12-26 Thread Srinivasa Rao Ragolu
Hi Joejing,

Thanks for quick reply. Above xml is getting generated fine if I set
vcpu_pin_set=1-12 in /etc/nova/nova.conf.

But how to pin each vcpu with pcpu something like below

cputune
   vcpupin vcpu=‘0’ cpuset=‘1-5,12-17’/

   vcpupin vcpu=‘1’ cpuset=‘2-3,12-17’/

/cputune


One more questions is Are Numa nodes are compulsory for pin each vcpu to pcpu?


Thanks,

Srininvas.




On Fri, Dec 26, 2014 at 4:37 PM, joejiang ifz...@126.com wrote:

 Hi Srinivasa,

 This section is related to cpu affinity in instance xml file.
  vcpu placement='static' cpuset='1-12'4/vcpu

 Regards,
 Joe Chiang



 At 2014-12-26 12:25:29, Srinivasa Rao Ragolu srag...@mvista.com wrote:

 Hi All,

 I have been working on CPU Pinning feature validation.

 I could able set vcpu_pin_set config in nova.conf and could able to see
 cpupin set in guest xml and working fine while launching.

 Please let me know how can I set cputune: vcpupin in guest xml?

 Or

 Any documents refer to validate cpu pinning use cases.

 Thanks,
 Srinivas.




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


Re: [openstack-dev] [CI][TripleO][Ironic] check-tripleo-ironic-xxx fails

2014-12-26 Thread James Polley
as I've said on https://bugs.launchpad.net/tripleo/+bug/1405732, suspecting
this comes from sudo pip is a good pointer - but as far as I can tell our
tripleo-ci scripts never run sudo pip.

This seems to be something that's happening before the testenv gets handed
to the tripleo-ci scripts. I've filed
https://review.openstack.org/#/c/144107/ to clean up all the uses of sudo
pip I can find in project-config, but I don't know if that will be
sufficient.

On Fri, Dec 26, 2014 at 12:13 PM, Denis Makogon dmako...@mirantis.com
wrote:



 On Fri, Dec 26, 2014 at 11:01 AM, Adam Gandelman ad...@ubuntu.com wrote:

 This is fallout from a new upstream release of pip that went out earlier
 in the week.  It looks like no formal bug ever got filed, tho the same
 problem discovered in devstack and trove's integration testing repository.
 Added some comments comments to the bug.


 Proper solution was merged into devstack (see [1]) and proposed for
 trove-integration (see [2]). So, it seems that we've faced with same
 problem across multiple projects that are relaying on pip.


 [1] https://review.openstack.org/#/c/143501
 [2] https://review.openstack.org/#/c/143746/

 Kind regards,
 Denis M.


 On Thu, Dec 25, 2014 at 10:59 PM, James Polley j...@jamezpolley.com
 wrote:

 Thanks for the alert

 The earliest failure I can see because of this is
 http://logs.openstack.org/43/141043/6/check-tripleo/check-tripleo-ironic-overcloud-precise-nonha/36c9771/

 I've raised https://bugs.launchpad.net/tripleo/+bug/1405732 and I've
 put some preliminary notes on
 https://etherpad.openstack.org/p/tripleo-ci-breakages

 On Fri, Dec 26, 2014 at 3:42 AM, ZhiQiang Fan aji.zq...@gmail.com
 wrote:

 check-tripleo-ironic-xxx failed because:

 rm -rf /home/jenkins/.cache/image-create/pypi/mirror/
 rm: cannot remove `/home/jenkins/.cache/image-create/pypi/mirror/':
 Permission denie

 see

 http://logs.openstack.org/37/143937/1/check-tripleo/check-tripleo-ironic-overcloud-precise-nonha/9be729b/console.html

 search on logstash.openstack.org:
 message:rm: cannot remove
 `/home/jenkins/.cache/image-create/pypi/mirror/\': Permission denied
 there are 59 hits in last 48 hours



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



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



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



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


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


[openstack-dev] [MagnetoDB] Andrey Ostapenko core nomination

2014-12-26 Thread isviridov
Hello stackers and magnetians,

I suggest nominating Andrey Ostapenko [1] to MagnetoDB cores.

During last months he has made huge contribution to MagnetoDB [2]
Andrey drives Tempest and python-magnetodbclient successfully.

Please rise your hands.

Thank you,
Ilya Sviridov

[1] http://stackalytics.com/report/users/aostapenko
[2] http://stackalytics.com/report/contribution/magnetodb/90




signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [MagnetoDB] Andrey Ostapenko core nomination

2014-12-26 Thread Dmitriy Ukhlov
Andrey is very active contributor, good team player and very helps us at
previous development cycle. +1 from my side.

On Fri, Dec 26, 2014 at 4:16 PM, isviridov isviri...@mirantis.com wrote:

 Hello stackers and magnetians,

 I suggest nominating Andrey Ostapenko [1] to MagnetoDB cores.

 During last months he has made huge contribution to MagnetoDB [2]
 Andrey drives Tempest and python-magnetodbclient successfully.

 Please rise your hands.

 Thank you,
 Ilya Sviridov

 [1] http://stackalytics.com/report/users/aostapenko
 [2] http://stackalytics.com/report/contribution/magnetodb/90





-- 
Best regards,
Dmitriy Ukhlov
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] ZeroMQ topic object.

2014-12-26 Thread Ilya Pekelny
Hi, all!

Unexpectedly I met a pretty significant issue when I have been solving a
small bug
https://bugs.launchpad.net/ubuntu/+source/oslo.messaging/+bug/1367614. The
problem is in several parts:

* Topics used for several purposes: to set subscriptions and to determine a
type of sockets.
* Topics is a strings which are modifying inline everywhere where it is
needed. So, the topic feature is very distributed and uncoordinated.

My issue with the bug was: It is impossible just hash topic somewhere and
not to crash all the driver.  Second part of the issue is: It is very
painful process to trace all the topic modifications which are distributed
though all the driver code.

After several attempts to fix the bug with small losses I concluded that
I need to create a control/entry point for topic string. Now I have a
proposal:

Blueprint —
https://blueprints.launchpad.net/oslo.messaging/+spec/zmq-topic-object
Spec — https://review.openstack.org/#/c/144149/
Patch — https://review.openstack.org/#/c/144120/

I want to discuss this feature and receive a feedbacks from a more
experienced rpc-Jedi.

Thanks!
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel] Feature delivery rules and automated tests

2014-12-26 Thread Aleksandra Fedorova
Actually with JJB in place we create jobs slower than without it.
Because we cannot just click through Jenkins web ui but have to
properly describe and test the job and make it pass the review
process. JJB helps to manage jobs but doesn't simplify job creation.

But let me point out that Jenkins job configuration is the least
important part of the task. The most troublesome part is to define the
exact scenario and implement environment for the job. Take, for
example, glustrefs cluster we needed to setup for plugins tests.

Thus, if we want CI job to be ready at SCF we need to get this
information in advance. Which means feature itself should have stable
interface and working test implementation several days before the
freeze.


On Wed, Dec 24, 2014 at 2:26 AM, Igor Shishkin ishish...@mirantis.com wrote:
 I believe yes.

 With jenkins job builder we could create jobs faster, QA can be involved in 
 that or even create jobs on their own.

 I think we have to try it during next release cycle, currently I can’t see 
 blockers/problems here.
 --
 Igor Shishkin
 DevOps



 On 24 Dec 2014, at 2:20 am GMT+3, Mike Scherbakov mscherba...@mirantis.com 
 wrote:

 Igor,
 would that be possible?

 On Mon, Dec 22, 2014 at 7:49 PM, Anastasia Urlapova aurlap...@mirantis.com 
 wrote:
 Mike, Dmitry, team,
 let me add 5 cents - tests per feature have to run on CI before SCF, it is 
 mean that jobs configuration also should be implemented.

 On Wed, Dec 17, 2014 at 7:33 AM, Mike Scherbakov mscherba...@mirantis.com 
 wrote:
 I fully support the idea.

 Feature Lead has to know, that his feature is under threat if it's not yet 
 covered by system tests (unit/integration tests are not enough!!!), and 
 should proactive work with QA engineers to get tests implemented and passing 
 before SCF.

 On Fri, Dec 12, 2014 at 5:55 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote:
 Guys,

 we've done a good job in 6.0. Most of the features were merged before 
 feature freeze. Our QA were involved in testing even earlier. It was much 
 better than before.

 We had a discussion with Anastasia. There were several bug reports for 
 features yesterday, far beyond HCF. So we still have a long way to be 
 perfect. We should add one rule: we need to have automated tests before HCF.

 Actually, we should have results of these tests just after FF. It is quite 
 challengeable because we have a short development cycle. So my proposal is 
 to require full deployment and run of automated tests for each feature 
 before soft code freeze. And it needs to be tracked in checklists and on 
 feature syncups.

 Your opinion?

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



 --
 Mike Scherbakov
 #mihgen


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



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



 --
 Mike Scherbakov
 #mihgen



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



-- 
Aleksandra Fedorova
Fuel Devops Engineer
bookwar

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


Re: [openstack-dev] [Fuel] Feature delivery rules and automated tests

2014-12-26 Thread Tatyanka
Hi all,
I agree with Alexandra about importance of the feature info on early 
implementation stage, 
And seems devops need to take part in review of specs too, clarify scenarios  
here and other data, that they need.

Отправлено с iPhone

 26 дек. 2014, в 19:36, Aleksandra Fedorova afedor...@mirantis.com 
 написал(а):
 
 Actually with JJB in place we create jobs slower than without it.
 Because we cannot just click through Jenkins web ui but have to
 properly describe and test the job and make it pass the review
 process. JJB helps to manage jobs but doesn't simplify job creation.
 
 But let me point out that Jenkins job configuration is the least
 important part of the task. The most troublesome part is to define the
 exact scenario and implement environment for the job. Take, for
 example, glustrefs cluster we needed to setup for plugins tests.
 
 Thus, if we want CI job to be ready at SCF we need to get this
 information in advance. Which means feature itself should have stable
 interface and working test implementation several days before the
 freeze.
 
 
 On Wed, Dec 24, 2014 at 2:26 AM, Igor Shishkin ishish...@mirantis.com 
 wrote:
 I believe yes.
 
 With jenkins job builder we could create jobs faster, QA can be involved in 
 that or even create jobs on their own.
 
 I think we have to try it during next release cycle, currently I can’t see 
 blockers/problems here.
 --
 Igor Shishkin
 DevOps
 
 
 
 On 24 Dec 2014, at 2:20 am GMT+3, Mike Scherbakov 
 mscherba...@mirantis.com wrote:
 
 Igor,
 would that be possible?
 
 On Mon, Dec 22, 2014 at 7:49 PM, Anastasia Urlapova 
 aurlap...@mirantis.com wrote:
 Mike, Dmitry, team,
 let me add 5 cents - tests per feature have to run on CI before SCF, it is 
 mean that jobs configuration also should be implemented.
 
 On Wed, Dec 17, 2014 at 7:33 AM, Mike Scherbakov mscherba...@mirantis.com 
 wrote:
 I fully support the idea.
 
 Feature Lead has to know, that his feature is under threat if it's not yet 
 covered by system tests (unit/integration tests are not enough!!!), and 
 should proactive work with QA engineers to get tests implemented and 
 passing before SCF.
 
 On Fri, Dec 12, 2014 at 5:55 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote:
 Guys,
 
 we've done a good job in 6.0. Most of the features were merged before 
 feature freeze. Our QA were involved in testing even earlier. It was much 
 better than before.
 
 We had a discussion with Anastasia. There were several bug reports for 
 features yesterday, far beyond HCF. So we still have a long way to be 
 perfect. We should add one rule: we need to have automated tests before HCF.
 
 Actually, we should have results of these tests just after FF. It is quite 
 challengeable because we have a short development cycle. So my proposal is 
 to require full deployment and run of automated tests for each feature 
 before soft code freeze. And it needs to be tracked in checklists and on 
 feature syncups.
 
 Your opinion?
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 --
 Mike Scherbakov
 #mihgen
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 --
 Mike Scherbakov
 #mihgen
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 -- 
 Aleksandra Fedorova
 Fuel Devops Engineer
 bookwar
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] [Mistral] Converging discussions on WF context and WF/task/action inputs

2014-12-26 Thread W Chan
 What you’re saying is that whatever is under “$.env” is just the exact same 
 environment that we passed when we started the workflow? If yes then it 
 definitely makes sense to me (it just allows to explicitly access 
 environment, not through the implicit variable lookup). Please confirm.

Yes. the $.env that I original proposed would be the same dict as the one
supplied at start_workflow.  Although we have to agree whether the
variables in the environment are allowed to change after the WF started.
Unless there's a valid use case, I would lean toward making env immutable.

 One thing that I strongly suggest is that we clearly define all reserved
keys like “env”, “__actions” etc. I think it’d be better if they all
started with the same prefix, for example, double underscore.

Agree. How about using double underscore for env as well (i.e.
$.__env.var1, $.__env.var2)?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Magnum] Proposed Changes to Magnum Core

2014-12-26 Thread Adrian Otto
Magnum Cores,

I propose the following addition to the Magnum Core group[1]:

+ Motohiro/Yuanying Otsuka (ootsuka)

Please let me know your votes by replying to this message.

Thanks,

Adrian

[1] https://review.openstack.org/#/admin/groups/473,members Current Members

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


Re: [openstack-dev] [MagnetoDB] Andrey Ostapenko core nomination

2014-12-26 Thread Ajaya Agrawal
+1

Cheers,
Ajaya

On Fri, Dec 26, 2014 at 8:22 PM, Dmitriy Ukhlov dukh...@mirantis.com
wrote:

 Andrey is very active contributor, good team player and very helps us at
 previous development cycle. +1 from my side.

 On Fri, Dec 26, 2014 at 4:16 PM, isviridov isviri...@mirantis.com wrote:

 Hello stackers and magnetians,

 I suggest nominating Andrey Ostapenko [1] to MagnetoDB cores.

 During last months he has made huge contribution to MagnetoDB [2]
 Andrey drives Tempest and python-magnetodbclient successfully.

 Please rise your hands.

 Thank you,
 Ilya Sviridov

 [1] http://stackalytics.com/report/users/aostapenko
 [2] http://stackalytics.com/report/contribution/magnetodb/90





 --
 Best regards,
 Dmitriy Ukhlov
 Mirantis Inc.

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


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


Re: [openstack-dev] [Openstack] Need help in validating CPU Pinning feature

2014-12-26 Thread Steve Gordon
- Original Message -
 From: Srinivasa Rao Ragolu srag...@mvista.com
 To: joejiang ifz...@126.com
 
 Hi Joejing,
 
 Thanks for quick reply. Above xml is getting generated fine if I set
 vcpu_pin_set=1-12 in /etc/nova/nova.conf.
 
 But how to pin each vcpu with pcpu something like below
 
 cputune
vcpupin vcpu=‘0’ cpuset=‘1-5,12-17’/
 
vcpupin vcpu=‘1’ cpuset=‘2-3,12-17’/
 
 /cputune
 
 
 One more questions is Are Numa nodes are compulsory for pin each vcpu to
 pcpu?

The specification for the CPU pinning functionality recently implemented in 
Nova is here:


http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/virt-driver-cpu-pinning.html

Note that exact vCPU to pCPU pinning is not exposed to the user as this would 
require them to have direct knowledge of the host pCPU layout. Instead they 
request that the instance receive dedicated CPU resourcing and Nova handles 
allocation of pCPUs and pinning of vCPUs to them.

Example usage:

* Create a host aggregate and add set metadata on it to indicate it is to be 
used for pinning, 'pinned' is used for the example but any key value can be 
used. The same key must used be used in later steps though::

$ nova aggregate-create cpu_pinning
$ nova aggregate-set-metadata 1 pinned=true

  NB: For aggregates/flavors that wont be dedicated set pinned=false.

* Set all existing flavors to avoid this aggregate::

$ for FLAVOR in `nova flavor-list | cut -f 2 -d ' ' | grep -o [0-9]*`; do 
nova flavor-key ${FLAVOR} set aggregate_instance_extra_specs:pinned=false; 
done

* Create flavor that has extra spec hw:cpu_policy set to dedicated. In this 
example it is created with ID of 6, 2048 MB of RAM, 20 GB drive, and 2 vCPUs::

$ nova flavor-create pinned.medium 6 2048 20 2
$ nova flavor-key 6 set hw:cpu_policy=dedicated

* Set the flavor to require the aggregate set aside for dedicated pinning of 
guests::

$ nova flavor-key 6 set aggregate_instance_extra_specs:pinned=true

* Add a compute host to the created aggregate (see nova host-list to get the 
host name(s))::

$ nova aggregate-add-host 1 my_packstack_host_name

* Add the AggregateInstanceExtraSpecsFilter and CPUPinningFilter filters to the 
scheduler_default_filters in /etc/nova.conf::

scheduler_default_filters = 
RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,

ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,

AggregateInstanceExtraSpecsFilter,CPUPinningFilter

  NB: On Kilo code base I believe the filter is NUMATopologyFilter

* Restart the scheduler::

# systemctl restart openstack-nova-scheduler

* After the above - with a normal (non-admin user) try to boot an instance with 
the newly created flavor::

$ nova boot --image fedora --flavor 6 test_pinning

* Confirm the instance has succesfully booted and that it's vCPU's are pinned 
to _a single_ host CPU by observing
  the cputune element of the generated domain XML::

# virsh list
 IdName   State

 2 instance-0001  running
# virsh dumpxml instance-0001
...
vcpu placement='static' cpuset='0-3'2/vcpu
  cputune
vcpupin vcpu='0' cpuset='0'/
vcpupin vcpu='1' cpuset='1'/
/cputune


-Steve


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


Re: [openstack-dev] [Magnum] Proposed Changes to Magnum Core

2014-12-26 Thread Steven Dake

On 12/26/2014 01:44 PM, Adrian Otto wrote:

Magnum Cores,

I propose the following addition to the Magnum Core group[1]:

+ Motohiro/Yuanying Otsuka (ootsuka)

Please let me know your votes by replying to this message.

Thanks,

Adrian

[1] https://review.openstack.org/#/admin/groups/473,members Current Members

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



+1 from me

Keep up the good work!
-steve


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


Re: [openstack-dev] [Magnum] Proposed Changes to Magnum Core

2014-12-26 Thread Davanum Srinivas
+1 welcome!
On Dec 26, 2014 3:48 PM, Adrian Otto adrian.o...@rackspace.com wrote:

 Magnum Cores,

 I propose the following addition to the Magnum Core group[1]:

 + Motohiro/Yuanying Otsuka (ootsuka)

 Please let me know your votes by replying to this message.

 Thanks,

 Adrian

 [1] https://review.openstack.org/#/admin/groups/473,members Current
 Members

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

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


Re: [openstack-dev] [Magnum] Proposed Changes to Magnum Core

2014-12-26 Thread Steven Dake

On 12/26/2014 01:44 PM, Adrian Otto wrote:

Magnum Cores,

I propose the following addition to the Magnum Core group[1]:

+ Motohiro/Yuanying Otsuka (ootsuka)

Please let me know your votes by replying to this message.

Thanks,

Adrian

[1] https://review.openstack.org/#/admin/groups/473,members Current Members

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


Abishek Chanda gave a +1 on IRC, but indicated his mail client is busted 
so voting in his proxy.  Feel free to sync on IRC if necessary :)


Regards
-steve


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


[openstack-dev] [Solum] Addition to solum core

2014-12-26 Thread Adrian Otto
Solum cores,

I propose the following addition to the solum-core group[1]:

+ Ed Cranford (ed--cranford)

Please reply to this email to indicate your votes.

Thanks,

Adrian Otto

[1] https://review.openstack.org/#/admin/groups/229,members Current Members

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


Re: [openstack-dev] [MagnetoDB] Andrey Ostapenko core nomination

2014-12-26 Thread Illia Khudoshyn
+1

-- 

Best regards,

Illia Khudoshyn,
Software Engineer, Mirantis, Inc.



38, Lenina ave. x-apple-data-detectors://1 Kharkov, Ukraine

www.mirantis.com http://www.mirantis.ru/

www.mirantis.ru



Skype: gluke_work

ikhudos...@mirantis.com

26 дек. 2014 г., в 15:16, isviridov isviri...@mirantis.com написал(а):

Hello stackers and magnetians,

I suggest nominating Andrey Ostapenko [1] to MagnetoDB cores.

During last months he has made huge contribution to MagnetoDB [2]
Andrey drives Tempest and python-magnetodbclient successfully.

Please rise your hands.

Thank you,
Ilya Sviridov

[1] http://stackalytics.com/report/users/aostapenko
[2] http://stackalytics.com/report/contribution/magnetodb/90
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev