Re: [openstack-dev] Proposing Kanagaraj Manickam and Ethan Lynn forheat-core

[Thomas Spatzier]

+1 on both from me!

Cheers,
Thomas

> From: Steve Baker 
> To: OpenStack Development Mailing List

> Date: 31/07/2015 06:37
> Subject: [openstack-dev] Proposing Kanagaraj Manickam and Ethan Lynn
> for heat-core
>
> I believe the heat project would benefit from Kanagaraj Manickam and
> Ethan Lynn having the ability to approve heat changes.
>
> Their reviews are valuable[1][2] and numerous[3], and both have been
> submitting useful commits in a variety of areas in the heat tree.
>
> Heat cores, please express your approval with a +1 / -1.
>
> [1] http://stackalytics.com/?user_id=kanagaraj-manickam&metric=marks
> [2] http://stackalytics.com/?user_id=ethanlynn&metric=marks
> [3] http://stackalytics.com/report/contribution/heat-group/90
>
>
__
> 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 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

Re: [openstack-dev] [all][infra] CI System is broken

[Gareth]

Could this issue be fixed today?

Btw, is it possible to design a special mode for gate/zuul? If ops switch
to that mode, all new gerrit event can't trigger any jenkins job.

On Thu, Jul 30, 2015 at 9:13 PM, Jeremy Stanley  wrote:

> On 2015-07-30 10:19:20 +0200 (+0200), Andreas Jaeger wrote:
> > Joshua just restarted Zuul and is currently requeueing the jobs
> > that were in the system.
> [...]
>
> Also we've got some additional debugging added prior to this most
> recent restart which should assist in narrowing down the cause
> if/when it happens again.
> --
> Jeremy Stanley
>
> __
> 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
>



-- 
Gareth

*Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball*
*OpenStack contributor, kun_huang@freenode*
*My promise: if you find any spelling or grammar mistakes in my email from
Mar 1 2013, notify me *
*and I'll donate $1 or ￥1 to an open organization you specify.*
__
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

Re: [openstack-dev] [packaging][all] setting minimum version of setuptools in setup.py

[Robert Collins]

On 30 July 2015 at 05:27, Robert Collins  wrote:
> Similar to pbr, we have a minimum version of setuptools required to
> consistently install things in OpenStack. Right now thats 17.1.
>
> However, we don't declare a setup_requires version for it.
>
> I think we should.
>
> setuptools can't self-upgrade, and we don't have declarative deps yet,
> so one reaction I expect here is 'how will this help'.
>
> The problem lies in the failure modes. With no dependency declared,
> setuptools will try and *silently fail*, or try and fail with this one
> weird error - that doesn't say anything about 'setuptools 3.3. cannot
> handle PEP 426 version markers'.
>
> If we set a minimum (but not a maximum) setuptools version as a
> setup_requires, I think we'll signal our actual dependencies to
> redistributors, and folk consuiming python packages, in a much more
> direct fashion. They'll still have to recover manually, but thats ok
> IMO. As long as we don't set upper bounds, we won't deadlock ourselves
> like we did in the past.

These are the errors we get with this when the version present is too-old:
Firstly, 0.6c11 which detects the error and reports it.
Then 3.3 which attempts to upgrade setuptools just-in-time but of
course the old setuptools code is what executes, and so the error is
confusing :/. But still better than no hint at all: the presence of
the setuptools upgrade is a signal.


$ pip install setuptools==0.6c11
...
Successfully installed setuptools-0.6rc11
$ pip install .
Processing /home/robertc/work/mock
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
  File "", line 20, in 
  File "/tmp/pip-wnBxi2-build/setup.py", line 6, in 
pbr=True)
  File "/usr/lib/python2.7/distutils/core.py", line 111, in setup
_setup_distribution = dist = klass(attrs)
  File 
"/home/robertc/.virtualenvs/test/local/lib/python2.7/site-packages/setuptools/dist.py",
line 260, in __init__
self.fetch_build_eggs(attrs.pop('setup_requires'))
  File 
"/home/robertc/.virtualenvs/test/local/lib/python2.7/site-packages/setuptools/dist.py",
line 284, in fetch_build_eggs
parse_requirements(requires), installer=self.fetch_build_egg
  File 
"/home/robertc/.virtualenvs/test/local/lib/python2.7/site-packages/pkg_resources.py",
line 569, in resolve
raise VersionConflict(dist,req) # XXX put more info here
pkg_resources.VersionConflict: (setuptools 0.6c11
(/home/robertc/.virtualenvs/test/lib/python2.7/site-packages),
Requirement.parse('setuptools>=17.1'))


Command "python setup.py egg_info" failed with error code 1 in
/tmp/pip-wnBxi2-build




$ pip install setuptools==3.3
Collecting setuptools==3.3
  Downloading setuptools-3.3-py2.py3-none-any.whl (545kB)
100% || 548kB 674kB/s
Installing collected packages: setuptools
  Found existing installation: setuptools 18.0.1
Uninstalling setuptools-18.0.1:
  Successfully uninstalled setuptools-18.0.1
Successfully installed setuptools-3.3
$ pip install .
Processing /home/robertc/work/mock
Complete output from command python setup.py egg_info:

Installed /tmp/pip-Grkk9a-build/setuptools-18.0.1-py2.7.egg
[pbr] Generating ChangeLog
error in setup command: Invalid environment marker:
(python_version<"3.3" and python_version>="3")


Command "python setup.py egg_info" failed with error code 1 in
/tmp/pip-Grkk9a-build

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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

Re: [openstack-dev] Proposing Kanagaraj Manickam and Ethan Lynn for heat-core

[Sergey Kraynev]

+1 from me for both.

Regards,
Sergey.

On 31 July 2015 at 07:35, Steve Baker  wrote:

> I believe the heat project would benefit from Kanagaraj Manickam and Ethan
> Lynn having the ability to approve heat changes.
>
> Their reviews are valuable[1][2] and numerous[3], and both have been
> submitting useful commits in a variety of areas in the heat tree.
>
> Heat cores, please express your approval with a +1 / -1.
>
> [1] http://stackalytics.com/?user_id=kanagaraj-manickam&metric=marks
> [2] http://stackalytics.com/?user_id=ethanlynn&metric=marks
> [3] http://stackalytics.com/report/contribution/heat-group/90
>
> __
> 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 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

Re: [openstack-dev] Proposing Kanagaraj Manickam and Ethan Lynn for heat-core

[Angus Salkeld]

On 31 Jul 2015 2:37 pm, "Steve Baker"  wrote:
>
> I believe the heat project would benefit from Kanagaraj Manickam and
Ethan Lynn having the ability to approve heat changes.
>
> Their reviews are valuable[1][2] and numerous[3], and both have been
submitting useful commits in a variety of areas in the heat tree.
>
> Heat cores, please express your approval with a +1 / -1.

+1 to both.

Angus
>
> [1] http://stackalytics.com/?user_id=kanagaraj-manickam&metric=marks
> [2] http://stackalytics.com/?user_id=ethanlynn&metric=marks
> [3] http://stackalytics.com/report/contribution/heat-group/90
>
> __
> 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 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

Re: [openstack-dev] Re： [neutron]How to use external_net?

[yatin kumbhare]

Hi,

I'm guessing tenant A is admin tenant.

Also, you can check the iptables NAT rules under router namespace in case
of ovs plugin.

You should find binding there.

Regards,
Yatin

On Fri, Jul 31, 2015 at 6:58 AM, 于洁 <16189...@qq.com> wrote:

> Thank you Cédric/ZZelle,
> I have tried this way before, but it could not realize the connection
> between two networks belongs to different tenants. So the floatingIP comes
> from tenant A could not bind to VM from tenant B.
> Do you have any suggestion about this?
> Thanks.
>
> YU
>
>
> -- 原始邮件 --
> *发件人:* "ZZelle";;
> *发送时间:* 2015年7月30日(星期四) 晚上7:21
> *收件人:* "OpenStack Development Mailing List (not for usage questions)"<
> openstack-dev@lists.openstack.org>;
> *主题:* Re: [openstack-dev] [neutron]How to use external_net?
>
> Hi,
>
> You need a router to bind internal network(s) with external network.
>
> Otherwise you cannot allocate a floating ip (on the external network) to
> VMs (on internal network(s)).
>
> The doc[1] explains how to do it.
>
> [1]
> http://docs.openstack.org/kilo/install-guide/install/apt/content/neutron_initial-tenant-network.html
>
>
> Cédric/ZZelle
>
>
> On Thu, Jul 30, 2015 at 1:08 PM, 于洁 <16189...@qq.com> wrote:
>
>> Hi all,
>>   I find that if setting the value of router:external=True for a
>> net(example: neutron net-update netID --router:external=True)
>>   Users in other tenants could allocate floating IP from this
>> net(example: neutron floatingip-create netID).
>>   But how could this floating IP bind to a VM created by the user
>> from other tenants? The network is unreachable.
>>   Or do I misunderstand the function?
>>
>> Thanks,
>> Yu
>>
>> __
>> 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 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 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-dev] Proposing Kanagaraj Manickam and Ethan Lynn for heat-core

[Steve Baker]

I believe the heat project would benefit from Kanagaraj Manickam and 
Ethan Lynn having the ability to approve heat changes.


Their reviews are valuable[1][2] and numerous[3], and both have been 
submitting useful commits in a variety of areas in the heat tree.


Heat cores, please express your approval with a +1 / -1.

[1] http://stackalytics.com/?user_id=kanagaraj-manickam&metric=marks
[2] http://stackalytics.com/?user_id=ethanlynn&metric=marks
[3] http://stackalytics.com/report/contribution/heat-group/90

__
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-dev] [fuel][fuel-library] Librarian changes

[Alex Schultz]

Hey everyone,

During on the fuel meeting today we discussed the librarian changes and
their status.
As part of this work, the wiki page was updated and a first attempt at
migrating the
following modules has been completed pending merge:

stdlib
concat
inifile
ssh
ntp
apache
firewall
xinetd
cinder
apt*

It should be noted that apt is currently blocked by the lack of a mirror so
while it has
been prepared, it should not be merged at this time.

As part of this migration we are doing two things. The first is an update
to the build
process that is included as part of the initial librarian[0] patch.  The
other patches
consist of the actual module code changes.

Here is the list of the diffs for each change so that it can be reviewed
and people can
raise concerns if there are any with this change. As part of the migration,
I inspected
the code and file differences for each module to determine how much impact
they might
have.  I chose the list of modules based on their minimal differences from
the upstream
or if they already had our forked differences rolled into a newer version
of the module.
For this list, I took the current stable iso (#110) and rebased the changes
on top of this
to create a custom iso with just the librarian changes. We have kicked off
a bvt_2 test for
the custom iso as well. From this iso I have extracted the fuel-library
package from both
of these isos and exploded the fuel-library folder structure to do the
diffs.

Code Changes:

For stdlib, the only differences are related to git, travis or
fixtures[1].  There are no
puppet code changes as part of the librarian migration.

For concat, the only differences were a git folder and in a custom change
to the spec tests[2].
The test difference[3], was a change we made because it was failing our
syntax checker.
This change has been included in a newer version of concat (1.2.4) but are
not necessary
when the module gets moved to be included via librarian.

For inifile, the only difference is the addition of git and metadata
files[4].

For ssh, the only difference is a single line to have the config notify
service[5]. This
difference is already covered by another file and is not needed[6].

For ntp, this change introduces more code changes[7] because we are
updating the module
to the 4.0.0 version because of previous extending of functionality that is
now covered by
4.0.0 vs 3.3.0[8]. The changes in our fork were upstreamed and are include
in 4.0.0.

For apache, this change includes an upgrade from 1.2.0 to 1.3.0[9][10]. Our
fork had a
customization made which was contributed upstream.
(apache::mod::proxy_connect)

For firewall, this change also includes an upgrade from 1.0.2 to 1.2.0[11]
as our fork had
mac supported added[12] in which is now covered upstream.

For xinetd, the only change was the addition of a .git folder and a
.gitignore with librarian.

For cinder, the only change was the addition of .git, .gitignore, and
.gitreview.

Once we can get the apt mirror created, the only change for that is also
the addition of
.git.


If there are any of these upgrades/changes that we do not want to tackle
right now, I can
adjust the review order such that it can be skipped for now.  Please take
some time to
review these changes and raise concerns.  So far CI has been successful on
all of these
changes, and bvt is currently running.

Also please take some time to review the changes themselves:
https://review.openstack.org/#/q/status:open+project:stackforge/fuel-library+branch:master+topic:bp/fuel-puppet-librarian,n,z

Please raise any concerns as quickly as possible as this is the last call
for objections
for these reviews.  This has been talked about extensively and these
reviews have
been available for several weeks now.

Thanks,
-Alex


[0] https://review.openstack.org/#/c/202763/
[1] http://paste.openstack.org/show/406523/
[2] http://paste.openstack.org/show/406524/
[3] http://paste.openstack.org/show/406525/
[4] http://paste.openstack.org/show/406526/
[5] http://paste.openstack.org/show/406527/
[6]
https://github.com/saz/puppet-ssh/blob/v2.4.0/manifests/server/config.pp#L9
[7] http://paste.openstack.org/show/406536/
[8] https://github.com/puppetlabs/puppetlabs-ntp/compare/3.3.0...4.0.0
[9] http://paste.openstack.org/show/406538/
[10] https://github.com/puppetlabs/puppetlabs-apache/compare/1.2.0...1.3.0
[11] https://github.com/puppetlabs/puppetlabs-firewall/compare/1.0.2...1.2.0
[12] https://review.openstack.org/#/c/92167/
__
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-dev] [ironic] baremetal server boot failing at iSCSI/tgtd

[Vikas Choudhary]

Hi Deva,

Thanks for replying on my problem.Actually i am using devstack for
deployment.For deployment also cirros kernel and ramdisk images  are
being used.I got issue resolved by using localrc from this link
http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html
In older localrc i was using few time-outs also may be those were
causing problem.


Thanks & Regards
Vikas

___

Hi Vikas,

It looks like the iscsi deploy process wasn't able to attach to the node.
This could be a network issue.

Also, what kernel and ramdisk are you using for the deploy step? Did you
download one, or build it with disk-image-builder? cirros is only suitable
for the instance image, not the deploy.

Regards,
-Deva
On Jul 29, 2015 5:56 PM, "Vikas Choudhary" http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>
wrote:

>* Hi,
*>* I am trying to boot an instance using pxe deployment process.I am using
*>* cirros-0.3.4-x86_64-uec image to boot the baremetal server VM.ramdisk and
*>* kernel images are being deployed successfully , but at kernel
*>* initialization time its getting stuck there.In console logs I can see that
*>* tgtd daemon is failing.
*>>* CONSOLE LOGS:
*>* Jul 29 23:17:18 (none) daemon.warn tgtd: tgtd logger started, pid:219
*>* debug:0^M
*>* waiting for tgtd socket...found^M
*>* Jul 29 23:17:19 (none) daemon.err tgtd: iser_ib_init(3351) Failed to
*>* initialize RDMA; load kernel modules?^M
*>* Jul 29 23:17:19 (none) daemon.err tgtd: work_timer_start(150) use signal
*>* based scheduler^M
*>* Jul 29 23:17:19 (none) daemon.err tgtd: bs_init_signalfd(271) could not
*>* open backing-store module directory /usr/lib/tgt/backing-store
*>>* ir-cond logs:
*>>* 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base [-] vendor_passthru
*>* failed with method pass_deploy_info
*>* 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base Traceback (most
*>* recent call last):
*>* 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base   File
*>* "/opt/stack/ironic/ironic/drivers/base.py", line 614, in passthru_handler
*>* 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base return
*>* func(*args, **kwargs)
*>* 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base   File
*>* "/opt/stack/ironic/ironic/conductor/task_manager.py", line 129, in wrapper
*>* 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base return f(*args,
*>* **kwargs)
*>* 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base   File
*>* "/opt/stack/ironic/ironic/drivers/modules/iscsi_deploy.py", line 815, in
*>* pass_deploy_info
*>* 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base
*>* uuid_dict_returned = continue_deploy(task, **kwargs)
*>* 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base   File
*>* "/opt/stack/ironic/ironic/drivers/modules/iscsi_deploy.py", line 392, in
*>* continue_deploy
*>* 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base
*>* _fail_deploy(task, msg)
*>* 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base   File
*>* "/opt/stack/ironic/ironic/drivers/modules/iscsi_deploy.py", line 365, in
*>* _fail_deploy
*>* 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base raise exception.
*>* InstanceDeployFailure(msg)
*>* 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base
*>* InstanceDeployFailure: Deploy failed for instance
42c3dea0-1f08-44f6-a38a-e6bd16d1212a.
*>* Error: Unexpected error while running command.
*>* 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base Command: sudo
*>* ironic-rootwrap /etc/ironic/rootwrap.conf iscsiadm -m discovery -t st -p
*>* 50.0.0.10:3260 
*>* 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base Exit code: 4
*>* 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base Stdout: u''
*>* 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base Stderr: u'iscsiadm:
*>* connect to 50.0.0.10 timed out\niscsiadm: connect to 50.0.0.10 timed
*>* out\niscsiadm: connect to 50.0.0.10 timed out\niscsiadm: connect to
*>* 50.0.0.10 timed out\niscsiadm: connect to 50.0.0.10 timed out\niscsiadm:
*>* connect to 50.0.0.10 timed out\niscsiadm: connection login retries
*>* (reopen_max) 5 exceeded\niscsiadm: Could not perform SendTargets discovery:
*>* encountered connection failure\n'
*>* 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base
*>* 2015-07-30 04:55:47.217 355 DEBUG ironic.conductor.task_manager [-]
*>* Successfully released exclusive lock for calling vendor passthru on node
*>* ac0a1e31-2545-4d26-988a-56134584721e (lock was held 496.37 sec)
*>* release_resources /opt/stack/ironic/ironic/conductor/task_manager.py:305
*>>* I would really appreciate any help/discussion/pointers.Please suggest.
*>>* __
*>* OpenStack Development Mailing List (not for usage questions)
*>* Unsubscribe: OpenStack-dev-request at lists.openstack.org
?subject:unsubscribe
*>* http

Re: [openstack-dev] How to use the log server in CI ?

[Tang Chen]

Hi Abhishek,


On 07/30/2015 04:54 PM, Abhishek Shrivastava wrote:

Hi Tang,

After completing the logServer installation the logs will go to your 
machine automatically after each build run.


I don't quite understand here. I didn't configure anything about jenkins 
in install_log_server.sh except the public SSH key.
How could jenkins find and connect to the log server ? Or how could the 
log server find the jenkins ?


Now, I can access to my log server index page. But when I run a build, 
no new log is put into /srv/static/logs/.


Thanks.





On Thu, Jul 30, 2015 at 2:19 PM, Tang Chen > wrote:


Hi Asselin, Abhishek,

Sorry, it is about the CI again.

I run install_log_server.sh to setup a log server.

I setup the log server on the same machine with my Jenkins Master,
and configured it like this:
$DOMAIN=localhost
$|JENKINS_SSH_PUBLIC_KEY| = path to my ssh key

The script completed. But I don't know how to use the log server.

Here are my questions:

1. Is the log server able to be on the same machine with Jenkins
Master ?
I think maybe the apache in the log server conflicts with the
jenkins server.


​ The answer to your question is no, as the logs generated​
​ each time will become large in size so it is recommended to use 
logServer on a separate machine having a public IP.



2. Is the log server able to upload the logs to Gerrit automatically ?
Or it is just a server for you to view the logs ?


​ The logs is not uploaded to Gerrit, only success or failure is 
reported to Gerrit. Also, when you click on the job in the gerrit with 
either of the message, you will be redirected to the logServer page.​



I raised an issue on github.  You can also discuss this on github
if you like.
(https://github.com/rasselin/os-ext-testing/issues/19)

I also asked about this in IRC #openstack-infra, but it seems that
very few people are using os-ext-testing.

Thanks.




--
*
*
*Thanks & Regards,
*
*Abhishek*
/_Cloudbyte Inc. _/


__
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

Re: [openstack-dev] [tricircle] DAL implementation

[Vega Cai]

Hi Joe,

I think one independent job is finished in one session. The job is
responsible to start  a session, query or modify database then end the
session. Like port creating job in neutron, it starts a session, queries
network, adds port, allocates ip address, then ends the session at the end.

BR
Zhiyuan

On 31 July 2015 at 09:05, joehuang  wrote:

> Hi, Vega,
>
>
>
> Multiple DB access will be a use case for one session , especially for DB
> data insertion, multiple table will be involved. To embed the session in
> Context, it’s ok to start a session if the session is empty, but how to
> decide when to commit the data, end a session?
>
>
>
> Best Regards
>
> Chaoyi Huang ( Joe Huang )
>
>
>
> *From:* Vega Cai [mailto:luckyveg...@gmail.com]
> *Sent:* Thursday, July 30, 2015 3:03 PM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] [tricircle] DAL implementation
>
>
>
> Hi folks,
>
>
>
> In my current implementation, there are a core module and a models module.
> Core module handles all the database stuff, start a session, issue sql
> operation, then end a session. Models module invokes methods in core module
> to access database, as showed below:
>
>
>
> model.py
>
> def get_site(site_id):
>
> core.get_resource(Site, site_id)
>
>
>
> core.py
>
> def get_resource(model, pk_value):
>
> # code to access database
>
>
>
> To add context, I am going to implement like this:
>
>
>
> model.py
>
> def get_site(context, site_id):
>
> policy_check(context)
>
> core.get_resource(Site, site_id)
>
>
>
> core.py
>
> def get_resource(model, pk_value):
>
> # code to access database
>
>
>
> So there is no need to embed session into context.
>
>
>
> One advantage of embedding session into context is that you can combine
> more than one method calls in one session, like:
>
>
>
> model.py
>
> def complex_operation(context):
>
> policy_check(context)
>
> with context.session.begin():
>
> core.operation1(context)
>
> core.operation2(context)
>
>
>
> But this approach moves session handling from core module to models module
> and core module just provides some utility methods.
>
>
>
> I'm not sure which one is better.
>
>
>
> BR
>
> Zhiyuan
>
> __
> 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 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-dev] Re?? [neutron]How to use external_net?

[????]

Thank you C??dric/ZZelle,
I have tried this way before, but it could not realize the connection between 
two networks belongs to different tenants. So the floatingIP comes from tenant 
A could not bind to VM from tenant B.
Do you have any suggestion about this?
Thanks.


YU




--  --
??: "ZZelle";;
: 2015??7??30??(??) 7:21
??: "OpenStack Development Mailing List (not for usage 
questions)"; 

: Re: [openstack-dev] [neutron]How to use external_net?



Hi,


You need a router to bind internal network(s) with external network.


Otherwise you cannot allocate a floating ip (on the external network) to VMs 
(on internal network(s)).


The doc[1] explains how to do it.

[1] 
http://docs.openstack.org/kilo/install-guide/install/apt/content/neutron_initial-tenant-network.html



C??dric/ZZelle











On Thu, Jul 30, 2015 at 1:08 PM,  <16189...@qq.com> wrote:
Hi all,
  I find that if setting the value of router:external=True for a 
net(example: neutron net-update netID --router:external=True)
  Users in other tenants could allocate floating IP from this net(example: 
neutron floatingip-create netID).
  But how could this floating IP bind to a VM created by the user from 
other tenants? The network is unreachable.
  Or do I misunderstand the function?


Thanks,
Yu

__
 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 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

Re: [openstack-dev] [tricircle] DAL implementation

[joehuang]

Hi, Vega,

Multiple DB access will be a use case for one session , especially for DB data 
insertion, multiple table will be involved. To embed the session in Context, 
it’s ok to start a session if the session is empty, but how to decide when to 
commit the data, end a session?

Best Regards
Chaoyi Huang ( Joe Huang )

From: Vega Cai [mailto:luckyveg...@gmail.com]
Sent: Thursday, July 30, 2015 3:03 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [tricircle] DAL implementation

Hi folks,

In my current implementation, there are a core module and a models module. Core 
module handles all the database stuff, start a session, issue sql operation, 
then end a session. Models module invokes methods in core module to access 
database, as showed below:

model.py
def get_site(site_id):
core.get_resource(Site, site_id)

core.py
def get_resource(model, pk_value):
# code to access database

To add context, I am going to implement like this:

model.py
def get_site(context, site_id):
policy_check(context)
core.get_resource(Site, site_id)

core.py
def get_resource(model, pk_value):
# code to access database

So there is no need to embed session into context.

One advantage of embedding session into context is that you can combine more 
than one method calls in one session, like:

model.py
def complex_operation(context):
policy_check(context)
with context.session.begin():
core.operation1(context)
core.operation2(context)

But this approach moves session handling from core module to models module and 
core module just provides some utility methods.

I'm not sure which one is better.

BR
Zhiyuan
__
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

Re: [openstack-dev] [nova, cinder, neutron] quota-update tenant-name bug

[Kevin Benton]

The issue is that the Neutron credentials might not have privileges to
resolve the name to a UUID. I suppose we could just fail in that case.

Let's see what happens with the nova spec Salvatore linked.

On Thu, Jul 30, 2015 at 4:33 PM, Fox, Kevin M  wrote:

> If the quota update resolved the name to a uuid before it updated the
> quota by uuid, I think it would resolve the issues? You'd just have to
> check if keystone was in use, and then do the extra resolve on update. I
> think the rest of the stuff can just remain using uuids?
>
> Thanks,
> Kevin
> --
> *From:* Kevin Benton [blak...@gmail.com]
> *Sent:* Thursday, July 30, 2015 4:22 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [nova, cinder, neutron] quota-update
> tenant-name bug
>
> Good point. Unfortunately the other issues are going to be the hard part
> to deal with. I probably shouldn't have brought up performance as a
> complaint at this stage. :)
>
> On Thu, Jul 30, 2015 at 3:26 AM, Fox, Kevin M  wrote:
>
>> Can a non admin update quotas? Quota updates are rare. Performance of
>> them can take the hit.
>>
>> Thanks,
>> Kevin
>>
>> --
>> *From:* Kevin Benton
>> *Sent:* Wednesday, July 29, 2015 10:44:49 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [nova, cinder, neutron] quota-update
>> tenant-name bug
>>
>> >Dev lessons learned: we need to validate better our inputs and refuse
>> to update a tenant-id that does not exist.
>>
>> This is something that has come up in Neutron discussions before. There
>> are two issues here:
>> 1. Performance: it will require a round-trip to Keystone on every request.
>> 2. If the Neutron keystone user in unprivileged and the request context
>> is unprivileged, we might not actually be allowed to tell if the tenant
>> exists.
>>
>> The first we can deal with, but the second is going to be an issue that
>> we might not be able to get around.
>>
>> How about as a temporary solution, we just confirm that the input is a
>> UUID so names don't get used?
>>
>> On Wed, Jul 29, 2015 at 10:19 PM, Bruno L  wrote:
>>
>>> This is probably affecting other people as well, so hopefully message
>>> will avoid some headaches.
>>>
>>> [nova,cinder,neutron] will allow you to do a quota-update using the
>>> tenant-name (instead of tenant-id). They will also allow you to do a
>>> quota-show tenant-name and get the expected values back.
>>>
>>> Then you go to the tenant and end up surprised that the quotas have not
>>> been applied and you can still do things you were not supposed to.
>>>
>>> It turns out that [nova,cinder,neutron] just created an entry on the
>>> quota table, inserting the tenant-name on the tenant-id field.
>>>
>>> "Surprise, surprise!"
>>>
>>> Ops lessons learned: use the tenant-id!
>>>
>>> Dev lessons learned: we need to validate better our inputs and refuse to
>>> update a tenant-id that does not exist.
>>>
>>> I have documented this behaviour on
>>> https://bugs.launchpad.net/neutron/+bug/1399065 and
>>> https://bugs.launchpad.net/neutron/+bug/1317515. I can reproduce it in
>>> IceHouse.
>>>
>>> Could someone please confirm if this is still the case on master? If
>>> not, which version of OpenStack addressed that?
>>>
>>> Thanks,
>>> Bruno
>>>
>>>
>>> __
>>> 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
>>>
>>>
>>
>>
>> --
>> Kevin Benton
>>
>> __
>> 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
>>
>>
>
>
> --
> Kevin Benton
>
> __
> 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
>
>


-- 
Kevin Benton
__
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

Re: [openstack-dev] [infra] Getting notified of closed pull requests on github?

[Joshua Harlow]

Clark Boylan wrote:

On Wed, Jul 29, 2015, at 09:14 AM, Joshua Harlow wrote:

Every now and then I go look at github to see what pull requests have
been auto-closed there, since it seems most of the repos under
https://github.com/openstack/(.*) auto-close pull requests (with
messages telling people to use gerrit);

I'm wondering though if there is anyway to notify the maintainers in
gerrit that this has happened?

For example anytime a PR is closed on say:

https://github.com/openstack/taskflow/pulls?q=is%3Apr+is%3Aclosed

A email could be sent to all of:

https://review.openstack.org/#/admin/groups/173,members

Letting those members there know that a PR was closed, and so that those
members can then try to avoid losing a contribution from a person that
was just trying to do 'good' (by making a PR in the first place).

Is anything like that possible, it would very much help in *not* losing
these types of contributions (and new members to our community) because
currently I have a feeling that most people don't even know that such
pull requests are getting closed automagically.

For example:

-
https://github.com/openstack/oslo.messaging/pulls?q=is%3Apr+is%3Aclosed
(3 here)
- https://github.com/openstack/nova/pulls?q=is%3Apr+is%3Aclosed (alot
here)
- https://github.com/openstack/glance/pulls?q=is%3Apr+is%3Aclosed (3
here)
-  and so on


Would it be simpler to subscribe to the projects on Gitub and have it
notify you directly of project activity?


Hmmm, good idea, might try that,

Other idea is that there could be a 
openstack-closed-pull-reque...@lists.openstack.org mailing list that 
cores/others could subscribe to if they want, and any time a automatic 
close happens, a mail gets sent to that list, then readers of that list 
can decide if they want to go find that person that made the PR and try 
to get it merged (I wonder if many people that submitted pull requests 
[and got it closed on them] even went through the effort to sign the 
ICLA/CCLA and submit a gerrit review, or did they just give up? Seems 
like that data should be somewhat easily determinable...)




Clark

__
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 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

Re: [openstack-dev] [nova, cinder, neutron] quota-update tenant-name bug

[Fox, Kevin M]

If the quota update resolved the name to a uuid before it updated the quota by 
uuid, I think it would resolve the issues? You'd just have to check if keystone 
was in use, and then do the extra resolve on update. I think the rest of the 
stuff can just remain using uuids?

Thanks,
Kevin

From: Kevin Benton [blak...@gmail.com]
Sent: Thursday, July 30, 2015 4:22 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova, cinder, neutron] quota-update tenant-name 
bug

Good point. Unfortunately the other issues are going to be the hard part to 
deal with. I probably shouldn't have brought up performance as a complaint at 
this stage. :)

On Thu, Jul 30, 2015 at 3:26 AM, Fox, Kevin M 
mailto:kevin@pnnl.gov>> wrote:
Can a non admin update quotas? Quota updates are rare. Performance of them can 
take the hit.

Thanks,
Kevin


From: Kevin Benton
Sent: Wednesday, July 29, 2015 10:44:49 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova, cinder, neutron] quota-update tenant-name 
bug

>Dev lessons learned: we need to validate better our inputs and refuse to 
>update a tenant-id that does not exist.

This is something that has come up in Neutron discussions before. There are two 
issues here:
1. Performance: it will require a round-trip to Keystone on every request.
2. If the Neutron keystone user in unprivileged and the request context is 
unprivileged, we might not actually be allowed to tell if the tenant exists.

The first we can deal with, but the second is going to be an issue that we 
might not be able to get around.

How about as a temporary solution, we just confirm that the input is a UUID so 
names don't get used?

On Wed, Jul 29, 2015 at 10:19 PM, Bruno L 
mailto:teolupus@gmail.com>> wrote:
This is probably affecting other people as well, so hopefully message will 
avoid some headaches.

[nova,cinder,neutron] will allow you to do a quota-update using the tenant-name 
(instead of tenant-id). They will also allow you to do a quota-show tenant-name 
and get the expected values back.

Then you go to the tenant and end up surprised that the quotas have not been 
applied and you can still do things you were not supposed to.

It turns out that [nova,cinder,neutron] just created an entry on the quota 
table, inserting the tenant-name on the tenant-id field.

"Surprise, surprise!"

Ops lessons learned: use the tenant-id!

Dev lessons learned: we need to validate better our inputs and refuse to update 
a tenant-id that does not exist.

I have documented this behaviour on 
https://bugs.launchpad.net/neutron/+bug/1399065 and 
https://bugs.launchpad.net/neutron/+bug/1317515. I can reproduce it in IceHouse.

Could someone please confirm if this is still the case on master? If not, which 
version of OpenStack addressed that?

Thanks,
Bruno

__
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




--
Kevin Benton

__
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




--
Kevin Benton
__
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

Re: [openstack-dev] [kolla] Mission change suggested by the TC for big tent

[Doug Hellmann]

Excerpts from Steven Dake (stdake)'s message of 2015-07-30 15:27:15 +:
> 
> On 7/29/15, 1:23 PM, "Doug Hellmann"  wrote:
> 
> >Excerpts from Steven Dake (stdake)'s message of 2015-07-29 20:07:26 +:
> >> Doug Hellman of the TC suggested we change the mission statement of
> >>Kolla to be a little less specific.  The new mission statement I
> >>submitted in the review is here Is basically cutting off the last part
> >>of the mission statement sentence:
> >> 
> >> https://review.openstack.org/#/c/206789/
> >> 
> >> If your a Kolla core eviewer, please vote ­1 (indicating you are a core
> >>reviewer in the review) if you dislike this change and think we should
> >>strive to keep our mission unchanged.  If you don¹t really have a strong
> >>preference, please abstain from voting as to not add non-useful
> >>information to the review.  Our core team knows what our true mission is
> >>and I don¹t think Doug¹s wording changes the mission significantly.
> >
> >My intent is not to change it at all, but to remove the "marketing
> >fluff", to be consistent with the nature of the missions described
> >by most of the other projects.  By all means, hold to those other
> >ideals and goals, but in the project list we want the mission to
> >say what you're doing as clearly and concisely as possible.
> >
> >Doug
> 
> Doug,
> 
> Its all good, I think the change you suggested simplifies the statement
> without changing the intent.  We can still do all those other things as
> you just indicated if we choose to.
> 
> I still want to give the core reviewer team an opportunity to vote on the
> change which is why I set the short deadline of Aug 3rd to vote -1 (and
> act as a veto vote) which would trigger irc meetings to rework the mission
> statement.

Sure, having the team vote & comment is absolutely appropriate, I
just wanted to clarify the reasons for the change. :-)

> Thanks for the good feedback, I actually think the modified mission
> statement is faster to say which is always a good thing :)

++

Doug

> 
> Regards
> -steve
> 
> >
> >> 
> >> I¹ll keep the schedule open until August 3rd and ask the TC to hold off
> >>on approving the submitted mission until the core team has not weighed
> >>in with a ­1 vote.  A vote of ­1 will count as a veto from the core
> >>reviewer team, and we will have to have some kind of super-brainstorming
> >>session like we did before to simplify the Kolla mission statement to
> >>something the TC would accept.
> >> 
> >> Regards
> >> -steve
> >
> >__
> >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 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

Re: [openstack-dev] [nova, cinder, neutron] quota-update tenant-name bug

[Kevin Benton]

Good point. Unfortunately the other issues are going to be the hard part to
deal with. I probably shouldn't have brought up performance as a complaint
at this stage. :)

On Thu, Jul 30, 2015 at 3:26 AM, Fox, Kevin M  wrote:

> Can a non admin update quotas? Quota updates are rare. Performance of them
> can take the hit.
>
> Thanks,
> Kevin
>
> --
> *From:* Kevin Benton
> *Sent:* Wednesday, July 29, 2015 10:44:49 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [nova, cinder, neutron] quota-update
> tenant-name bug
>
> >Dev lessons learned: we need to validate better our inputs and refuse to
> update a tenant-id that does not exist.
>
> This is something that has come up in Neutron discussions before. There
> are two issues here:
> 1. Performance: it will require a round-trip to Keystone on every request.
> 2. If the Neutron keystone user in unprivileged and the request context is
> unprivileged, we might not actually be allowed to tell if the tenant exists.
>
> The first we can deal with, but the second is going to be an issue that we
> might not be able to get around.
>
> How about as a temporary solution, we just confirm that the input is a
> UUID so names don't get used?
>
> On Wed, Jul 29, 2015 at 10:19 PM, Bruno L  wrote:
>
>> This is probably affecting other people as well, so hopefully message
>> will avoid some headaches.
>>
>> [nova,cinder,neutron] will allow you to do a quota-update using the
>> tenant-name (instead of tenant-id). They will also allow you to do a
>> quota-show tenant-name and get the expected values back.
>>
>> Then you go to the tenant and end up surprised that the quotas have not
>> been applied and you can still do things you were not supposed to.
>>
>> It turns out that [nova,cinder,neutron] just created an entry on the
>> quota table, inserting the tenant-name on the tenant-id field.
>>
>> "Surprise, surprise!"
>>
>> Ops lessons learned: use the tenant-id!
>>
>> Dev lessons learned: we need to validate better our inputs and refuse to
>> update a tenant-id that does not exist.
>>
>> I have documented this behaviour on
>> https://bugs.launchpad.net/neutron/+bug/1399065 and
>> https://bugs.launchpad.net/neutron/+bug/1317515. I can reproduce it in
>> IceHouse.
>>
>> Could someone please confirm if this is still the case on master? If not,
>> which version of OpenStack addressed that?
>>
>> Thanks,
>> Bruno
>>
>> __
>> 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
>>
>>
>
>
> --
> Kevin Benton
>
> __
> 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
>
>


-- 
Kevin Benton
__
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

Re: [openstack-dev] [infra] Getting notified of closed pull requests on github?

[Clark Boylan]

On Wed, Jul 29, 2015, at 09:14 AM, Joshua Harlow wrote:
> Every now and then I go look at github to see what pull requests have 
> been auto-closed there, since it seems most of the repos under 
> https://github.com/openstack/(.*) auto-close pull requests (with 
> messages telling people to use gerrit);
> 
> I'm wondering though if there is anyway to notify the maintainers in 
> gerrit that this has happened?
> 
> For example anytime a PR is closed on say:
> 
> https://github.com/openstack/taskflow/pulls?q=is%3Apr+is%3Aclosed
> 
> A email could be sent to all of:
> 
> https://review.openstack.org/#/admin/groups/173,members
> 
> Letting those members there know that a PR was closed, and so that those 
> members can then try to avoid losing a contribution from a person that 
> was just trying to do 'good' (by making a PR in the first place).
> 
> Is anything like that possible, it would very much help in *not* losing 
> these types of contributions (and new members to our community) because 
> currently I have a feeling that most people don't even know that such 
> pull requests are getting closed automagically.
> 
> For example:
> 
> - 
> https://github.com/openstack/oslo.messaging/pulls?q=is%3Apr+is%3Aclosed 
> (3 here)
> - https://github.com/openstack/nova/pulls?q=is%3Apr+is%3Aclosed (alot
> here)
> - https://github.com/openstack/glance/pulls?q=is%3Apr+is%3Aclosed (3
> here)
> -  and so on
> 
Would it be simpler to subscribe to the projects on Gitub and have it
notify you directly of project activity?

Clark

__
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

Re: [openstack-dev] Quick question..

[Iury Gregory]

Hi Adam, te deafult criteria is two +2 and +1 in Workflow.
More information you can find in
http://docs.openstack.org/infra/manual/developers.html


2015-07-30 19:33 GMT-03:00 Kevin L. Mitchell :

> On Thu, 2015-07-30 at 15:27 -0700, Adam Lawson wrote:
> > How many "up" votes are needed for code to be accepted into the trunk
> > (assuming it passes testing etc)?
>
> Which project?  Different projects may have different criteria.
> --
> Kevin L. Mitchell 
> Rackspace
>
>
> __
> 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
>



-- 

~


*Att[]'sIury Gregory Melo Ferreira **Master student in Computer Science at
UFCG*
*E-mail:  iurygreg...@gmail.com *
~
__
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

Re: [openstack-dev] Quick question..

[Kevin L. Mitchell]

On Thu, 2015-07-30 at 15:27 -0700, Adam Lawson wrote:
> How many "up" votes are needed for code to be accepted into the trunk
> (assuming it passes testing etc)?

Which project?  Different projects may have different criteria.
-- 
Kevin L. Mitchell 
Rackspace


__
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-dev] Quick question..

[Adam Lawson]

How many "up" votes are needed for code to be accepted into the trunk
(assuming it passes testing etc)?


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
__
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

Re: [openstack-dev] The proposed "Neutron API extension for packet forwarding" has a lot of duplication to the Neutron SFC API

[Anita Kuno]

On 07/31/2015 01:45 AM, Armando M. wrote:
> On 29 July 2015 at 22:42, Anita Kuno  wrote:
> 
>> On 07/29/2015 02:37 PM, Armando M. wrote:
>>> Hi,
>>>
>>> Since I was quoted, I would like to take the blame on behalf on the
>> Neutron
>>> core reviewer/drivers team for not providing the right guidance to
>> resolve
>>> the apparent conflict between the two proposals.
>>>
>>> As some reviewers mentioned, we should really strive to catch two birds
>>> with one stone, and ensure that, if at all possible, the same API can
>>> address both use cases presented. In this case, it sounds to me that the
>>> API proposed by the networking-sfc sub-project is more comprehensive, it
>>> has taken the steps to evolve independently from the Neutron core
>> platform,
>>> and it has been iterated on multiple times. Surely we can spin off (the
>>> forwarding engine) from the spin off (the SFC API), but that would feel
>>> like an overkill, especially when both have very little code to show for
>>> (and everyone knows that code wins in OpenStack).
>>>
>>> We should have provided Yuji Azama feedback a lot earlier in the process
>>> but we didn't. Again, blame me!
>>>
>>> I think that Sean raised a flag which should be seen as an acknowledgment
>>> of a need to reconcile the two efforts; let's move past the blame game
>> and
>>> the language barriers, and let's figure out how to address Yuji's need
>>> within the context of a single effort, without dismissing it. For this
>>> reason I am going to suggest we iterate within the networking-sfc
>> project,
>>> and block change 186663 .
>> Let's
>>> figure out how the model/API has to evolve to accommodate the proposed
>> used
>>> need.
>>>
>>> If you disagree, please raise your concern on the patch in review itself.
>>>
>>> Cheers,
>>> Armando
>>
>> Hi Armando,
>>
>> If my attempts to offer some feedback on communication came across as
>> blame than I failed in what I was trying to accomplish.
> 
> 
>> My goal was and is to try to illustrate the point that competition and
>> collaboration are two separate directions.
>>
>> While some folks come from a competitive background, I hold the vision
>> of OpenStack as a collaborative experience. Some folks many need more
>> time than others to understand and digest the differences in behaviour
>> associated with the two styles of operating.
>>
>> I appreciate your email, Armando. At the very least it sets a good
>> example for others who many be new to collaboration to follow.
>>
>> As always, it is a pleasure to work with you Armax,
>> Anita.
> 
> 
> My point was simply to encourage the people involved in both efforts to
> take action after the discussion. The resolution of using one API over the
> other did not translate into a patch in any of our repos to capture the
> conclusion, at least not until now anyway, and without that, any
> back-and-forth is moot.
> 
> That said, I think it's important that you keep us honest along our journey
> :)
> 
> Thank you!

Thanks Armando,
Anita.

> 
> 
>>
>>>
>>> On 28 July 2015 at 15:01, Sean M. Collins  wrote:
>>>
 All,

 My suggestion was as follows:

>  I'd say maybe an e-mail to the ML, with the results of this
 meeting, and say that we want to try and converge where
> there is commonality

 I think there is overlap between the two APIs. Let's keep collaborating
 on both the networking-sfc and packet forwarding APIs, to see where we
 have commonality. I think Cathy's initial e-mail may have ruffled
 feathers - and I'd like to smooth them out again. I think the statement
 "we only need one API" is far too premature.

 Let's play nice with the other API proposals, yes?


 --
 Sean M. Collins


>> __
 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 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 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 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

Re: [openstack-dev] [Ceilometer] Unable to get the neutron network related meters in ceilometer

[gord chung]

On 30/07/2015 1:55 PM, Srikanth Vavilapalli wrote:

I was able to resolve this issue by adding the following configuration line (by 
default, disable_non_metric_meters is set to True, and most of the Neutron 
meters are of type non-metric)  in /etc/ceilometer/ceilometer.conf and 
restarting all ceilometer services.. Hope this helps others...

[notification]
disable_non_metric_meters = false


to followup, in Ceilometer, we capture data in two different models: 
Meters and Events[1]. Meters are designed for numeric, measurement data 
such as: cpu time, cpu_util, incoming.bytes, etc... Events are a more 
generic model which represent the state of a resource. historically, we 
never had Events so we captured non-measurement data (see Neutron 
'meters') as Meters. going forward, consumers should enable store_events 
(if not already) to capture non-measurement data as Events. Events offer 
better granularity and are more query-able.


[1] 
http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-events.html


cheers,

--
gord


__
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

Re: [openstack-dev] [TripleO] [app-catalog] TripleO, Advanced Services, and the App Catalog

[James Slagle]

On Sat, Jul 25, 2015 at 4:00 PM, Fox, Kevin M  wrote:
> I'm not really sure how to start this conversation so I'll just start in.
> Please bare with me for a bit.
>
> Something of a problem description:
> With my Operator hat on, I've been quite interested in adopting TripleO. Due
> to many reasons, its been hard for me to to explore as much as I'd like.
> While time is one reason, another is its kind of monolithic. To try it out,
> the best way so far has been to try and use it all.
>
> We've been interested in deploying some advanced services on our clouds to
> add features for our users. Again, due to limited time limitations, I
> haven't been able to explore as many of them as I would have liked.
>
> Some of the advanced services we've had a chance to play with, to varying
> degrees are Sahara, Trove, Designate, and Barbican. We'd also like to play
> with Manilla, Octavia, Murano, Mistral, Magnum, etc. The majority of these
> services can be deployed in VM's (or Containers) running within the Cloud
> and then provided through the Cloud.
>
> Proposal:
> So that got me thinking. Could the TripleO deployment template set be broken
> up in such a way that it could be used to augment an existing cloud
> deployment instead of just deploying a fresh cloud? This would allow Clouds
> to add advanced features such as Manilla before the Cloud distribution they
> are running on supports it. Also, to make it easy for this enhancement to be
> discoverable, they could be added to the application catalog:
> http://apps.openstack.org. As the App Catalog UI gets integrated further
> with Horzion, it would make it very easy for Operators to extend their
> clouds with Advanced services. They would just do a quick search, hit
> Launch, and fill out a simple form.

Yes, I think it would be possible. It would take a little work to get
there though, as I don't expect it to work today without someone
diving into the templates and starting to try it out, and fixing
mistakes and possibly some bad assumptions that were made, etc.

What you're proposing though I think is very compelling. Ideally, you
could take just the compute template from tripleo-heat-templates and
use Heat to deploy a ResourceGroup of compute nodes. Since the
implementation in the templates is so heavily reliant on provider
templates and nested stacks, I think it could work without large
architectural changes.

You'd have to manually pass in via parameters to the compute template
what would usually be passed in by the parent template in a full
TripleO deployment. For instance, the compute-puppet.yaml template
takes a KeystoneHost parameter. When deploying a cloud with TripleO,
that IP address is known to Heat since it asked Nova to launch the
instance running Keystone, so it passes in that IP address as the
value for KeystoneHost. Without Heat orchestrating the parent template
as well, you'd have to pass this parameter in manually. Not a huge
deal, but it would be a fair amount of manual work that is usually
handled by the Heat orchestration automatically.

Assuming the cloud had Ironic, you could even use this method to scale
out an existing cloud not deployed with TripleO onto more baremetal
machines, not just things that can run in VM's. Effectively, it's Heat
scaling out the same cloud Heat is running on. We've had similar
thoughts before about doing such a thing to scale out a TripleO
undercloud so that the seed vm is no longer needed.

I think we've developed (and continue to do so) some good patterns in
tripleo-heat-templates to not make things so tightly coupled. The
puppet implementation proved that out and helped drive a lot of that.
We've been able to build on that, and do things like deploy a puppet
based controller, and a docker based compute node by just swapping out
the compute template. So, I think we're continuing to move towards
having less coupling, and that's a good thing.

There is also some preliminary work going on into looking at using
Heat to configure already running instances that are not known to
Nova. Since most (all?) of the configuration of instances is driven
via SoftwareDeployments, it serves to reason that if you created a
Heat stack that was a bunch of SoftwareDeployments (as TripleO does),
and then configured os-collect-config on an already installed system
that you could then run os-collect-config and apply those
SoftwareDeployments. This requires mapping the OS::Nova::Server
resource to a custom resource that you then map to a nested stack that
doesn't actually launch an instance. This would allow someone to make
use of all the work that has gone into the templates about how to
install and configure OpenStack, but use less of OpenStack itself to
take advantage of it.

-- 
-- James Slagle
--

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.o

Re: [openstack-dev] [Ironic] Let's talk about API versions

[Devananda van der Veen]

On Thu, Jul 30, 2015 at 10:21 AM Clint Byrum  wrote:

> Excerpts from Jim Rollenhagen's message of 2015-07-27 13:35:25 -0700:
> > Hi friends.
> >
> > Ironic implemented API "micro" versions in Kilo. We originally did this
> > to allow for breaking changes in the API while allowing users to opt in
> > to the breakage.
> >
> > Since then, we've had a "default version" for our client that we bump to
> > something sensible with each release. Currently it is at 1.8.
> > Negotiation is done with the server to figure out what is supported and
> > adjust accordingly.
> >
> > Now we've landed a patch[0] with a new version (1.11) that is not
> > backward compatible. It causes newly added Node objects to begin life in
> > the ENROLL state, rather than AVAILABLE. This is a good thing, and
> > people should want this! However, it is a breaking change. Automation
> > that adds nodes to Ironic will need to do different things after the
> > node-create call.
> >
>
> Great discussion. I think through this thread I've gained some insight
> into what is going on, and I think the problem is that minor version
> bumps are not for backward incompatible changes. As a user, I want to
> pin everything and move the pins after I've tested and adapted with new
> versions of things. However, I also don't want to have to micro manage
> this process while I move forward on different schedules with my REST
> clients and the Ironic service.
>
> So, to be clear, I may have missed what you're trying to do with micro
> versions.
>
> In my world, a 1.10 -> 1.11 would be for adding new methods, new
> arguments, or deprecating (but not removing) an existing piece of the
> API. But changing the semantics of an existing thing is a major version
> bump. So I wonder if the right thing to do is to bump to 2.0, make the
> default in the client 1.10* for now, with deprecation warnings that the
> major version will not be assumed for future client libraries, and move
> on with the understanding that micro versions aren't supposed to break
> users of a particular major version.
>
> Thoughts?
>
> * I'm assuming it is possible to make micro version changes to the 1.x API
>   as 1.10.1, 1.10.2,etc
>
>
Despite most folks calling this "microversions", I have been trying to
simply call this "API version negotiation".

To your question, no -- the implementations by Nova and Ironic, and the
proposal that the API-WG has drafted [1], do not actually support
MAJOR.MINOR.PATCH semantics.

It has been implemented as a combination of an HTTP request to
"http(s):" plus a header
"X-OpenStack--API-Version:
.".

The  version number is duplicated in both the URI and the header,
though Ironic will error if they do not match. Also, there is no  or
 version.

So, were we to change the  version in the header, I would expect
that we also change it in the URL, which means registering a new endpoint
with Keystone, and, well, all of that.

-D

[1] https://review.openstack.org/#/c/187112/
__
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-dev] [api] PATCH guidelines concerning body content

[michael mccune]

hi all,

recently a discussion came up in irc[1] about the guidance we can 
provide concerning PATCH body contents. essentially the issue comes down 
to what we should be recommending for updating resources; rfc6902 type 
patching, partial resource updates on PATCH, or a different methodology 
akin to sub-resource updating.


it seems reasonable that regardless of the methodology a project 
chooses, that the project should remain consistent internally. 
furthermore, it sounds like there are a number of different 
implementations in use around the openstack ecosystem which makes it 
more difficult to recommend a singular approach. although we could 
choose a direction as "most advisable".


we currently mention PATCH[2], and both 6902 and partial resource style 
updates. i'd like to open a discussion around what type of guidance we 
can provide in this area. i see a few options we could explore for 
guidelines:


* choosing a consistent updating methodology
* advising a sensible choice as the default preference of the wg (6902, 
partial resource, sub-resource)

* providing examples

what do folks think about creating some specific guidance for updating 
resources?


regards,
mike

[1]: 
http://eavesdrop.openstack.org/irclogs/%23openstack-api/%23openstack-api.2015-07-28.log.html#t2015-07-28T21:49:08


[2]: 
http://specs.openstack.org/openstack/api-wg/guidelines/http.html#http-methods


__
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

Re: [openstack-dev] [packaging][all] setting minimum version of setuptools in setup.py

[Robert Collins]

On 30 July 2015 at 13:12, Clay Gerrard  wrote:
> I agree an error message is better than breaking for insane reasons.
>
> But... maybe as an aside... what about not breaking?
>
> How come the openstack ecosystem doesn't have wait for PEP 426 to be
> approved and for setuptools 17.1 to be widely deployed before it can
> require/depend on it?  Is there no failure/degraded case where we can take
> advantage of moving forward in the infrastructure where we apparently need
> it - but not necessarily force everyone else to upgrade if it's not directly
> solving something for them (e.g. people doing packaging of openstack
> projects, but don't personally necessarily currently maintain or distribute
> a setuptools package)?
>
> On the web this happens all the time "Sure maybe you can't get the newest
> HTML5 wiz-bang, but I can still render something on IE8, OTOH, IE7, wow -
> pls upgrade" vs. "How are you not even running setuptools 17.1 right now in
> your build environment - it was *literally* released *almost* two months
> ago!?  I... I can't even... it hurts to look at you."
>
> Just Curious.
>
> I only recently found out that PEP 426 was a thing, so I think it's pretty
> great to see people driving the python packaging ecosystem forward.  For
> those involved.  Kudos.

So, we [folk in OpenStack that are worried about our packaging] got
involved with upstream pip, setuptools, PEP-426 etc after some years
of trying the 'use whats ready, and workaround the rest by layering on
top' approach.

That approach led us to:
 - a nearly diametrically opposite definition of requirements files,
which confuses approximately everyone that reads the pip docs and not
the pbr ones - and vice versa.
 - a pattern of emergent bugs where we failed to consider a corner
case because we worked around the surface, which emerges as a  bad
behaviour. For instance, our non-compliant version numbers in pbr <
0.10.8 (IIRC the point # correctly). Or the way requirements-py3.txt
files caused use to create universal wheels with bad metadata that
couldn't install properly on other Python releases than the one they
were built on.
 - a chunk of overlapping effort, where setuptools and pip were
tackling the same stuff we were, because we're not that special a
snowflake: many folk experience the pains we feel from packaging
limits...  but not benefiting from what we'd learnt, nor from the
effort we put in.

So - for OpenStack as a whole, just consuming the current state and
working around was a buggy expensive strategy. And *even with that* we
still required the latest release of pip, setuptools and virtualenv
simply because we would run into a bug, get it fixed, and need to
consume it in devstack: devstack installs the latest of these four
(add pbr) crucial packaging tools unconditionally and has for a long
time.

So right now I, and a few others, are pushing on:
 - Aligning our designs with the ecosystem for less waste and
confusion all around.
 - Doing the work we had previously done as layered workarounds as
root level patches to the various tools

While still rolling out the new things, whatever they are, within
OpenStack before we consider them delivered.

HTH,
Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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

Re: [openstack-dev] [puppet] Parameters possible default value

[Andrew Woodward]

On Thu, Jul 30, 2015 at 3:36 AM Sebastien Badia  wrote:

> On Mon, Jul 27, 2015 at 09:43:28PM (+), Andrew Woodward wrote:
> > Sorry, I forgot to finish this up and send it out.
> >
> > #--SNIP--
> > def absent_default(
> >   $value,
> >   $default,
> >   $unset_when_default = true,
> > ){
> >   if ( $value == $default ) and $unset_when_default {
> > # I cant think of a way to deal with this in a define so lets pretend
> > # we can re-use this with multiple providers like we could if this
> was
> > # in the actual provider.
> >
> > keystone_config {$name: ensure => absent,}
> >   } else {
> > keystone_config {$name: value = $value,}
> >   }
> > }
> >
> > # Usage:
> > absent_default{'DEFAULT/foo': default => 'bar', value => $foo }
>
> Hi,
>
> Hum, but you want to add this definition in all our modules, or directly in
> openstacklib?
>

I only mocked it up in a puppet define, because its easier for me (my ruby
is terrible) It should be done by adding these kinds of extra providers to
the inifile provider override that Yanis proposed.


>
> In case of openstacklib, in which manner do you define the
> _config
> resource? (eg, generic def, but specialized resource).
>
> > #--SNIP--
> >
> > (I threw this together and haven't tried to run it yet, so It might not
> run
> > verbatim, I will create a test project with it to show it working)
> >
> > So In the long-term we should be able to add some new functionality to
> the
> > inifile provider to simply just do this for us. We can add the 'default'
> > and 'unset_when_default' parameter so that we can use them straight w/o a
> > wrapping function (but the warping function could be used too). This
> would
> > give us the defaults (I have an idea on that too that I will try to put
> > into the prototype) that should allow us to have something that looks
> quite
> > clean, but is highly functional
> >
> > > Keystone_config{unset_when_default => true} #probably flatly enabled in
> > our inifile provider for the module
> > > keystone_config {'DEFAULT/foo': value => 'bar', default => 'bar'}
>
>
> I'm not sure to see the difference with the Yanis solution here¹, and not
> sure
> to see the link between the define resource and the type/provider resource.
>

This adds on to Yanis' solution so that we can authoritatively understand
what the default value is, and how it should be treated (instead of hoping
some magic word doesn't conflict)

Seb
>
> ¹https://review.openstack.org/#/c/202574/
> --
> Sebastien Badia
> __
> 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
>
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
__
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

Re: [openstack-dev] [infra][puppet] Keeping common set of file synchronized across puppet modules

[Colleen Murphy]

On Wed, Jul 29, 2015 at 5:40 AM, Jeremy Stanley  wrote:

> On 2015-07-29 10:53:38 +0200 (+0200), Yanis Guenane wrote:
> > On 07/28/2015 07:13 PM, Andreas Jaeger wrote:
> [...]
> > > * If there is a proposed change already for a project, reuse that one
> > > instead of creating a new one?
> >
> > I don't have the answer for that I'd have to look. But this should never
> > happen as the goal here is to enforce a process where a change to a
> > shared file can only be done via the modulesync repository.
>
> The question comes from experience preforming similar
> synchronization proposals for requirements lists, translations, data
> file normalization, et cetera. Specifically, if you update the msync
> repo and that triggers change proposals for all your module repos,
> but then core reviewers don't get around to approving at least some
> of those before the next change merges to the msync repo (especially
> possible if you approve two msync changes at roughly the same time),
> will it properly update the existing but not-yet-merged changes it
> previously proposed rather than creating new changes?
>
No, it would create a new set of changes that for the entire the current
state of the modulesync-configs repository (not just the latest change), so
any unmerged changes from the last sync would have to be manually
abandoned, or the new changes would have to be manually rebased on the old
changes.

>
> > > * Will msync check out the git repositories itself?
> >
> > Yes, msync checks out the repositories listed in managed_modules.yml,
> > loop on them, clone them, apply the templates and submit the review.
>
> Also, does msync know to take advantage of the on-disk cache of git
> repositories on our job workers, or does it clone them all over the
> network every time it runs? The latter can lead to additional
> fragility.
>
It can take any URI as a remote, so it can clone from the local filesystem
if we tell it to.

> --
> Jeremy Stanley


Modulesync is a beta tool that is in danger of being massively rewritten[1]
and has the potential to allow you to shoot yourself in the foot[2].
Multiple people have suggested that it over-reaches its primary function by
trying to do too many things. Its main value-add is the ability to template
files that are /slightly/ different between repositories. I suspect that
this is something we don't need, so if there is already synchronization
tooling in place in the OpenStack world it makes sense to use that.

Colleen

[1] https://github.com/puppet-community/modulesync/pull/52
[2]
http://lists.openstack.org/pipermail/openstack-infra/2015-July/002965.html
__
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

Re: [openstack-dev] [neutron][lbaas] Help on single create call

[Brandon Logan]

One of the features we were hoping to get into Liberty for neutron-lbaas v2 was 
a single create call.  This call would be one that would accept an entire 
configuration tree of loadbalancer, listeners, pools, members, and health 
montiors in the API and create all of it (and also rolling back correctly when 
soemthing fails).


I'm not going to be having a lot of time to get this done, even though it is 
something I've wanted.  I just wouldn't be able to get to it until some time 
after the Liberty feature freeze.  I'm emailing this out to get some feelers if 
someone in the community would be willing to give this an attempt.  I'd 
definitely help out on it and collaboratively brainstorm when necessary.


Let me know.


Thanks,
Brandon
__
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-dev] [openstack-ansible] [os-ansible-deployment] Kilo -> Liberty Upgrade Problems

[Ian Cordasco]

Hey all,

As you may have seen elsewhere on openstack-dev, OpenStack is changing the
versioning for the service projects. This means our previous upgrade
solution will not continue to work. For context, one of our project's
goals is to have in-place upgrades be a reality. Previously, using our
repository (package) mirror doing:

# pip install -U {{servicename}}

Was perfectly fine. The problem will now occur that 2015.1.0 (kilo) is
more recent than any of the new service version numbers (as far as pip is
concerned). This would be resolved if the release management team for
OpenStack properly used an epoch to indicate that the versioning scheme is
fundamentally different and something like Glance 8.0.0 should sort after
Glance 2015.1.0, but they won't (for reasons that you can read in earlier
threads on this list).

So, in order to satisfy the goal of in-place upgrades, we need a way
around this. Currently, we use a tool called 'yaprt' to build wheels and
repository indices for our project. This tool can (and currently does)
create reports of the built files and exports those reports as JSON. We
can use this to know the version generated for a service and then instead
do:

# pip install {{servicename}}=={{yaprt_generated_version}}

This will force pip to ignore the fact that the existing (kilo)
installation is actually supposed to sort as more recent because you're
telling it to install a very specific version. This will likely need to be
our upgrade path going forward unless we also require operators to clear
out their existing repository mirror of packages with Kilo versions (and
then we can go back to relying on pip's version sorting semantics to do
pip install -U {{servicename}}).

This is, at the moment, the seemingly simplest way to work around the
brokenness that is the upstream versioning change.

If you can think of a different way of approaching this, we'd love to hear
it. If not, Kevin or myself will probably start working on this approach
in a week or two so it's ready for when Liberty is actually released and
we can start testing upgrades from the kilo branch to master (which is
currently tracking liberty).

Cheers,
Ian

__
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

Re: [openstack-dev] [neutron][lbaas] questions about scenario tests

[Madhusudhan Kandadai]

Debugging helped solving the issue faced in Jenkins. Per our conversation,
I shall be testing TLS LB scenario and keep you posted if I come across
anything.

Madhu


On Mon, Jul 27, 2015 at 10:47 AM, Phillip Toohill <
phillip.tooh...@rackspace.com> wrote:

>  ​Wonder if this is the same behavior as the TLS scenario? I have some
> higher priorities but I am attempting to debug the TLS test in between
> doing other things. Ill let you know if I come across anything.
>
>
>   Phillip V. Toohill III
> Software Developer
>  phone: 210-312-4366
> mobile: 210-440-8374
>
>   --
> *From:* Madhusudhan Kandadai 
> *Sent:* Sunday, July 26, 2015 10:48 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [neutron][lbaas] questions about scenario tests
>
> Hi there,
>
>  We have two working scenario tests in neutron lbaas tree and those are
> getting succeeded locally, however when running them in Jenkins, it is
> behaving differently: One of them got passed and the other one is facing
> time-out issues when trying to curl two backend servers after setting up
> two simple webservers. Both the tests are using the same base.py to setup
> backend servers. For info:
> https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/tests/tempest/v2/scenario
>
>  Tried increasing the default ping_timeout from 120 to 180, but no luck.
> Their logs are shown here:
> http://logs.openstack.org/13/205713/4/experimental/gate-neutron-lbaasv2-dsvm-scenario/09bbbd1/
>
>  If anyone has any idea about this, could you shed some light on the same?
>
>  Thanks!
>
> Madhu
>
> __
> 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 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

Re: [openstack-dev] [Ceilometer] Unable to get the neutron network related meters in ceilometer

[Srikanth Vavilapalli]

I was able to resolve this issue by adding the following configuration line (by 
default, disable_non_metric_meters is set to True, and most of the Neutron 
meters are of type non-metric)  in /etc/ceilometer/ceilometer.conf and 
restarting all ceilometer services.. Hope this helps others... 

[notification]
disable_non_metric_meters = false

Thanks
Srikanth


-Original Message-
From: Srikanth Vavilapalli [mailto:srikanth.vavilapa...@ericsson.com] 
Sent: Wednesday, July 29, 2015 2:25 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Ceilometer] Unable to get the neutron network related 
meters in ceilometer

Hi

I have manually installed latest ceilometer service in my devstack (master 
branch) cluster with MongoDB as backend. I have configured all the ceilometer 
services (notification, central, collector, api services on controller node and 
 ceilometer-agent-compute on compute nodes) as per the installation guide. Also 
I have enabled "nova", "glance", "cinder" and "neutron" to send notifications 
to oslo messaging queue by modifying the corresponding .conf file. 

When I run "ceilometer meter-list" command, I can see only the meters from 
compute, glance and cinder, but not from "neutron" service. Could any of 
provide me any pointers on how I can troubleshoot this issue? Plz let me know 
if you need any info from my setup..

Thanks
Srikanth

__
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 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-dev] [neutron] Service Chain project IRC meeting minutes - 07/30/2015

[Cathy Zhang]

Hi Everyone,

Thanks for joining the service chaining project meeting on 7/30/2015. Here is 
the link to the meeting logs:
http://eavesdrop.openstack.org/meetings/service_chaining/2015/

Thanks,
Cathy
__
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

Re: [openstack-dev] [Ironic] Let's talk about API versions

[Clint Byrum]

Excerpts from Jim Rollenhagen's message of 2015-07-27 13:35:25 -0700:
> Hi friends.
> 
> Ironic implemented API "micro" versions in Kilo. We originally did this
> to allow for breaking changes in the API while allowing users to opt in
> to the breakage.
> 
> Since then, we've had a "default version" for our client that we bump to
> something sensible with each release. Currently it is at 1.8.
> Negotiation is done with the server to figure out what is supported and
> adjust accordingly.
> 
> Now we've landed a patch[0] with a new version (1.11) that is not
> backward compatible. It causes newly added Node objects to begin life in
> the ENROLL state, rather than AVAILABLE. This is a good thing, and
> people should want this! However, it is a breaking change. Automation
> that adds nodes to Ironic will need to do different things after the
> node-create call.
> 

Great discussion. I think through this thread I've gained some insight
into what is going on, and I think the problem is that minor version
bumps are not for backward incompatible changes. As a user, I want to
pin everything and move the pins after I've tested and adapted with new
versions of things. However, I also don't want to have to micro manage
this process while I move forward on different schedules with my REST
clients and the Ironic service.

So, to be clear, I may have missed what you're trying to do with micro
versions.

In my world, a 1.10 -> 1.11 would be for adding new methods, new
arguments, or deprecating (but not removing) an existing piece of the
API. But changing the semantics of an existing thing is a major version
bump. So I wonder if the right thing to do is to bump to 2.0, make the
default in the client 1.10* for now, with deprecation warnings that the
major version will not be assumed for future client libraries, and move
on with the understanding that micro versions aren't supposed to break
users of a particular major version.

Thoughts?

* I'm assuming it is possible to make micro version changes to the 1.x API
  as 1.10.1, 1.10.2,etc

__
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

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

[Rich Megginson]

On 07/30/2015 10:54 AM, Matthew Mosesohn wrote:

The problem appears to be much more concise. The provider sets
identity_api_version okay, but doesn't alter OS_AUTH_URL api version.
That's the only reason why this is breaking.

It is broken in 2 places: in openstacklib's credentials class and in
keystone base provider. The keystone auth_endpoint logic seems to just
duplicate that of openstacklib's credentials class, so I think it
would make sense to consolidate that. I will prepare a patch to
puppet-keystone and puppet-openstacklib to address this.


Ok.  Please add me to the reviews.



On Thu, Jul 30, 2015 at 6:14 PM, Rich Megginson  wrote:

On 07/30/2015 08:53 AM, Matthew Mosesohn wrote:

Hi Rich,

Sorry, I meant to link [0] to
https://bugs.launchpad.net/keystone/+bug/1470635
More responses inline.


On Thu, Jul 30, 2015 at 5:38 PM, Rich Megginson 
wrote:

There is a patch upstream[1] that enables V3 service endpoint
creation, but v2.0 users/clients will not see these endpoints.


Right.  I'm not sure what the problem is - v3 clients can see the
endpoints
created with v2.


But not vice versa.


But you said "We are using Keystone v2.0 API everywhere currently." - Are
you trying to move to use v3?

Not yet.


I'm still not sure what the problem is.  Are you trying to move to use v3
for auth, and use v3 resources like domains?

No. Avoiding that is better for now.

Option 1: Keep v2.0 API data in openrc and hack v3 keystone providers,
updating ENV with 2 vars:
OS_IDENTITY_API_VERSION=3
OS_AUTH_URL=$(echo "$OLD_OS_AUTH_URL" | sed -e s'/v2.0/v3/')
or their equivalent in command line parameters


I don't understand.  When you say "v3 keystone providers" are you talking
about the puppet-keystone openstack.rb providers?  If so, they already do
something similar to the above.

Yes, the puppet-keystone openstack.rb providers. Almost, except they don't
update the identity_api_version. It just passes the version from ENV
or $HOME/openrc


https://github.com/openstack/puppet-openstacklib/blob/master/lib/puppet/provider/openstack/credentials.rb


Ok, I see.  The intention of that code is that, if you specify something in
ENV/openrc, it will override the default settings in the provider.

What if the puppet-keystone openstack providers did not allow you to
override the api version/url version with ENV/openrc?  Would that solve the
problem?


Option 2: Update to v3 Identity API for all services and accept the
unmerged patch[1]. This route requires the most disruptive changes
because of [0] and I would like to avoid this.


I don't understand why you need [1] which makes keystone_endpoint use the
v3
api.  v3 clients can see endpoints created with the v2 api.

Updating all clients to v3 is more effort at this point and v3
keystone is not targeted for Fuel 7.0.


Option 3: Revert puppet-keystone to version 5.1.0 which is before v3
became mandatory.


I'd like to see what is possible with Option 1 because it should be
possible to use the existing providers in puppet-keystone master
without too many hoops to make them all work cleanly. I'd really
prefer being able to provide all these parameters to the keystone
provider, rather than relying on the /root/openrc file or exporting
shell vars, but getting this issue unstuck is really the most
important.


I'm still not sure what the issue is, what you are prevented from doing.

The issue, concisely, is creating service_endpoints with v2.0 API and
other keystone resources with v3 API using one /root/openrc file.

__
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 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 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 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-dev] Ryan chairing IRC meeting of August 5th

[Steven Dake (stdake)]

Folks,

I will be at the Magnum midcycle August 5th and August 6th in SJC so I will be 
unavailable to run the IRC meeting during this time.  Ryan Hallisey has 
graciously agreed to chair the meeting in my absence.  Bmace has also offered 
to act as a backup in the case that both I or Ryan are unavailable in the 
future for our IRC meetings.

Regards
-steve
__
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

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

[Matthew Mosesohn]

The problem appears to be much more concise. The provider sets
identity_api_version okay, but doesn't alter OS_AUTH_URL api version.
That's the only reason why this is breaking.

It is broken in 2 places: in openstacklib's credentials class and in
keystone base provider. The keystone auth_endpoint logic seems to just
duplicate that of openstacklib's credentials class, so I think it
would make sense to consolidate that. I will prepare a patch to
puppet-keystone and puppet-openstacklib to address this.

On Thu, Jul 30, 2015 at 6:14 PM, Rich Megginson  wrote:
> On 07/30/2015 08:53 AM, Matthew Mosesohn wrote:
>>
>> Hi Rich,
>>
>> Sorry, I meant to link [0] to
>> https://bugs.launchpad.net/keystone/+bug/1470635
>> More responses inline.
>>
>>
>> On Thu, Jul 30, 2015 at 5:38 PM, Rich Megginson 
>> wrote:

 There is a patch upstream[1] that enables V3 service endpoint
 creation, but v2.0 users/clients will not see these endpoints.
>>>
>>>
>>> Right.  I'm not sure what the problem is - v3 clients can see the
>>> endpoints
>>> created with v2.
>>>
>> But not vice versa.
>>
>>> But you said "We are using Keystone v2.0 API everywhere currently." - Are
>>> you trying to move to use v3?
>>
>> Not yet.
>>
>>> I'm still not sure what the problem is.  Are you trying to move to use v3
>>> for auth, and use v3 resources like domains?
>>
>> No. Avoiding that is better for now.

 Option 1: Keep v2.0 API data in openrc and hack v3 keystone providers,
 updating ENV with 2 vars:
 OS_IDENTITY_API_VERSION=3
 OS_AUTH_URL=$(echo "$OLD_OS_AUTH_URL" | sed -e s'/v2.0/v3/')
 or their equivalent in command line parameters
>>>
>>>
>>> I don't understand.  When you say "v3 keystone providers" are you talking
>>> about the puppet-keystone openstack.rb providers?  If so, they already do
>>> something similar to the above.
>>
>> Yes, the puppet-keystone openstack.rb providers. Almost, except they don't
>> update the identity_api_version. It just passes the version from ENV
>> or $HOME/openrc
>>
>>
>> https://github.com/openstack/puppet-openstacklib/blob/master/lib/puppet/provider/openstack/credentials.rb
>
>
> Ok, I see.  The intention of that code is that, if you specify something in
> ENV/openrc, it will override the default settings in the provider.
>
> What if the puppet-keystone openstack providers did not allow you to
> override the api version/url version with ENV/openrc?  Would that solve the
> problem?
>
>>
 Option 2: Update to v3 Identity API for all services and accept the
 unmerged patch[1]. This route requires the most disruptive changes
 because of [0] and I would like to avoid this.
>>>
>>>
>>> I don't understand why you need [1] which makes keystone_endpoint use the
>>> v3
>>> api.  v3 clients can see endpoints created with the v2 api.
>>
>> Updating all clients to v3 is more effort at this point and v3
>> keystone is not targeted for Fuel 7.0.
>>
 Option 3: Revert puppet-keystone to version 5.1.0 which is before v3
 became mandatory.


 I'd like to see what is possible with Option 1 because it should be
 possible to use the existing providers in puppet-keystone master
 without too many hoops to make them all work cleanly. I'd really
 prefer being able to provide all these parameters to the keystone
 provider, rather than relying on the /root/openrc file or exporting
 shell vars, but getting this issue unstuck is really the most
 important.
>>>
>>>
>>> I'm still not sure what the issue is, what you are prevented from doing.
>>
>> The issue, concisely, is creating service_endpoints with v2.0 API and
>> other keystone resources with v3 API using one /root/openrc file.
>>
>> __
>> 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 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 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

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Igor Kalnitsky]

Hi there,

Tags have been pushed. They could be checked on the main Git repo [1]
or GitHub mirror [2].

Thanks,
igor

[1]: http://git.openstack.org/cgit/stackforge/fuel-plugins/
[2]: https://github.com/stackforge/fuel-plugins/releases

On Thu, Jul 30, 2015 at 7:02 PM, Sheena Gregson  wrote:
> Ah, my mistake - yes, please push tags for all of the plugin builder
> versions.
>
> -Original Message-
> From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com]
> Sent: Thursday, July 30, 2015 10:47 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
>
> Hi guys,
>
> @Sergii, you didn't pay attention. Evgeny Li has provided a ticket to fix it
> [1].
>
> @Sheena, fuel_plugins_builder isn't associated with Fuel releases.
> Here's a list of all versions:
>
> fuel-plugin-builder 2.0.4
> fuel-plugin-builder 2.0.3
> fuel-plugin-builder 2.0.2
> fuel-plugin-builder 2.0.1
> fuel-plugin-builder 2.0.0
> fuel-plugin-builder 1.0.2
> fuel-plugin-builder 1.0.1
>
> I can push tags for them.
>
> Thanks,
> Igor
>
> [1] https://bugs.launchpad.net/fuel/+bug/1479785
>
> On Thu, Jul 30, 2015 at 5:54 PM, Sheena Gregson 
> wrote:
>> I would imagine we would want tags for any releases that have plugins
>> associated, or we are planning to have plugins associated (so, 6.0,
>> 6.1, 7.0).
>>
>> -Original Message-
>> From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com]
>> Sent: Thursday, July 30, 2015 9:46 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
>>
>> Hi Sheena,
>>
>> Sure, I can do it. Should I push tag only for last release or for all
>> releases that are available on PyPI?
>>
>> Thanks,
>> Igor
>>
>> On Thu, Jul 30, 2015 at 5:29 PM, Sheena Gregson
>> 
>> wrote:
>>> So the only cores are Igor and Evgeniy?  Can one of you add tags for
>>> the new release versions?
>>>
>>>
>>>
>>> From: Sebastian Kalinowski [mailto:skalinow...@mirantis.com]
>>> Sent: Thursday, July 30, 2015 8:02 AM
>>>
>>>
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> 
>>> Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2015-07-30 14:50 GMT+02:00 Evgeniy L :
>>>
>>> Hi Sheena,
>>>
>>>
>>>
>>> Created ticket to change the structure of the directories [1].
>>>
>>> And as far as I know any core can push tags into the repository,
>>>
>>> Sebastian, Igor and I.
>>>
>>>
>>>
>>> One correction: I'm not a core in fuel-plugins ;)
>>>
>>>
>>>
>>>
>>>
>>> [1] https://bugs.launchpad.net/fuel/+bug/1479785
>>>
>>>
>>>
>>> On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson
>>> 
>>> wrote:
>>>
>>> Evgeniy –
>>>
>>>
>>>
>>> For the items which you have listed actions, who should be
>>> responsible for next steps?
>>>
>>>
>>>
>>> Sheena
>>>
>>>
>>>
>>> From: Evgeniy L [mailto:e...@mirantis.com]
>>> Sent: Tuesday, July 28, 2015 11:54 AM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> 
>>> Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
>>>
>>>
>>>
>>> Hi Sergii, thank you for feedback,
>>>
>>>
>>>
> c. There is no documentation how to install fpb from github master
> branch. It's very useful for developers who want to use latest
> version. We should add something
>>>
>>>
>>>
>>> We had a documentation, but removed it because the newer fpb was
>>> released,
>>>
>>> probably we should add this information permanently [1].
>>>
>>>
>>>
> a. We are doing the same mistake putting all things into one basket.
> There should be 2 repositories. One for examples and one for fpb.
> What's the goal of keeping fpb in directory and examples on top?
>>>
>>>
>>>
>>> These plugins are the data which are required for integration
>>> testing,
>>>
>>> we test that plugin build is not broken, which we run when patch gets
>>>
>>> published. I see nothing wrong with having the data for integration
>>> testing
>>>
>>> in the same repository with product which should be tested.
>>>
>>> Also in previous release we *removed* all the plugins which are not
>>>
>>> related to the builder itself, lbaas and glusterfs.
>>>
>>>
>>>
> This breaks a couple of things
>>>
>>>
>>>
>>> Having data for testing in the repository doesn't break anything.
>>>
>>>
>>>
> b. I cannot build fpm with simple
>>>
>>>
>>>
>>> That is a good point, we should move code from fuel_plugin_builder
>>> directory
>>>
>>> on top level, and move data for testing into examples directory.
>>>
>>>
>>>
> c. There is no tags as I can see only stable/6.0
>>>
>>>
>>>
>>> Correct, tags should be added.
>>>
>>>
>>>
> d. There are no tests to improve code quality pep8 flask8, code
> coverage
>>>
>>>
>>>
>>> That is not true, there are more then one hundreds unit tests which
>>> we run
>>>
>>> for each patch with python 2.6 and python 2.7, also there are
>>> integration tests
>>>
>>> which check that for each patch we don't brea

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Sheena Gregson]

Ah, my mistake - yes, please push tags for all of the plugin builder
versions.

-Original Message-
From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com]
Sent: Thursday, July 30, 2015 10:47 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback

Hi guys,

@Sergii, you didn't pay attention. Evgeny Li has provided a ticket to fix it
[1].

@Sheena, fuel_plugins_builder isn't associated with Fuel releases.
Here's a list of all versions:

fuel-plugin-builder 2.0.4
fuel-plugin-builder 2.0.3
fuel-plugin-builder 2.0.2
fuel-plugin-builder 2.0.1
fuel-plugin-builder 2.0.0
fuel-plugin-builder 1.0.2
fuel-plugin-builder 1.0.1

I can push tags for them.

Thanks,
Igor

[1] https://bugs.launchpad.net/fuel/+bug/1479785

On Thu, Jul 30, 2015 at 5:54 PM, Sheena Gregson 
wrote:
> I would imagine we would want tags for any releases that have plugins
> associated, or we are planning to have plugins associated (so, 6.0,
> 6.1, 7.0).
>
> -Original Message-
> From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com]
> Sent: Thursday, July 30, 2015 9:46 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
>
> Hi Sheena,
>
> Sure, I can do it. Should I push tag only for last release or for all
> releases that are available on PyPI?
>
> Thanks,
> Igor
>
> On Thu, Jul 30, 2015 at 5:29 PM, Sheena Gregson
> 
> wrote:
>> So the only cores are Igor and Evgeniy?  Can one of you add tags for
>> the new release versions?
>>
>>
>>
>> From: Sebastian Kalinowski [mailto:skalinow...@mirantis.com]
>> Sent: Thursday, July 30, 2015 8:02 AM
>>
>>
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
>>
>>
>>
>>
>>
>>
>>
>> 2015-07-30 14:50 GMT+02:00 Evgeniy L :
>>
>> Hi Sheena,
>>
>>
>>
>> Created ticket to change the structure of the directories [1].
>>
>> And as far as I know any core can push tags into the repository,
>>
>> Sebastian, Igor and I.
>>
>>
>>
>> One correction: I'm not a core in fuel-plugins ;)
>>
>>
>>
>>
>>
>> [1] https://bugs.launchpad.net/fuel/+bug/1479785
>>
>>
>>
>> On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson
>> 
>> wrote:
>>
>> Evgeniy –
>>
>>
>>
>> For the items which you have listed actions, who should be
>> responsible for next steps?
>>
>>
>>
>> Sheena
>>
>>
>>
>> From: Evgeniy L [mailto:e...@mirantis.com]
>> Sent: Tuesday, July 28, 2015 11:54 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
>>
>>
>>
>> Hi Sergii, thank you for feedback,
>>
>>
>>
 c. There is no documentation how to install fpb from github master
 branch. It's very useful for developers who want to use latest
 version. We should add something
>>
>>
>>
>> We had a documentation, but removed it because the newer fpb was
>> released,
>>
>> probably we should add this information permanently [1].
>>
>>
>>
 a. We are doing the same mistake putting all things into one basket.
 There should be 2 repositories. One for examples and one for fpb.
 What's the goal of keeping fpb in directory and examples on top?
>>
>>
>>
>> These plugins are the data which are required for integration
>> testing,
>>
>> we test that plugin build is not broken, which we run when patch gets
>>
>> published. I see nothing wrong with having the data for integration
>> testing
>>
>> in the same repository with product which should be tested.
>>
>> Also in previous release we *removed* all the plugins which are not
>>
>> related to the builder itself, lbaas and glusterfs.
>>
>>
>>
 This breaks a couple of things
>>
>>
>>
>> Having data for testing in the repository doesn't break anything.
>>
>>
>>
 b. I cannot build fpm with simple
>>
>>
>>
>> That is a good point, we should move code from fuel_plugin_builder
>> directory
>>
>> on top level, and move data for testing into examples directory.
>>
>>
>>
 c. There is no tags as I can see only stable/6.0
>>
>>
>>
>> Correct, tags should be added.
>>
>>
>>
 d. There are no tests to improve code quality pep8 flask8, code
 coverage
>>
>>
>>
>> That is not true, there are more then one hundreds unit tests which
>> we run
>>
>> for each patch with python 2.6 and python 2.7, also there are
>> integration tests
>>
>> which check that for each patch we don't break validation and that we
>> can
>>
>> build plugins for previous versions. Plus there are functional tests
>> which are
>>
>> written by fuel-qa team, those tests check that we perform deployment
>>
>> with plugins and required functionality works correctly. Also there
>> *is*
>> pep8
>>
>> check [2].
>>
>>
>>
 e. Repository doesn't follow community standards.
>>
>>
>>
>> I think this issue should be resolved with moving fuel_plugin_builder
>> directory
>>
>> on level higher, if not, please provide more specific

Re: [openstack-dev] [Ironic] Let's talk about API versions

[Chris Friesen]

On 07/30/2015 12:55 AM, Michael Davies wrote:


On Tue, Jul 28, 2015 at 6:05 AM, Jim Rollenhagen mailto:j...@jimrollenhagen.com>> wrote:

[snip]

It seems to me we have a few options here:

1) Default the python client and CLI to the earliest supported version.
This will never break users by default.

2) Default the python client and CLI to use the special version
'latest'. This will always use the latest API version, and always
break people when a new server version (that is not backwards
compatible) is deployed.

3) Do what Nova does[1]. Default CLI to latest and python client to
earliest. This assumes that CLI is typically used for one-time commands
(and it isn't a big deal if we break a one-off command once), and the
python client is used for applications.

4) Require a version to use the client at all. This would be a one-time
break with how applications initialize the client (perhaps we could fall
back to the earliest version or something for a deprecation period).
This isn't a great user experience, however, it's the best way to get
users to think about versioning. And no, "this requires typing another
argument every time!" is not a valid argument against this; we already
require a number of arguments, anyone sane doesn't type --ironic-api-url
or --os-username every time they use the client.

5) Do what we're doing now. Bump the client's default version with every
release. This mostly hides these versions from end users, and in general
those users probably won't know they exist. And then we run into
arguments every time we want to make a breaking change to the API. :)

I think I like option 1 or 3 the best. I certainly don't like option 5
because we're going to break users every time we release a new client.

What do other folks think we should do?


Thanks jroll for bringing this up!

Isn't the problem here that we're treating breaking and non-breaking changes
similarly?

Didn't we previously say that major backward incompatible changes should require
a major version bump?

What if we adopted a semver or similar scheme for API versioning?  What if we
required 'Major' (in Major.Minor.Patch) to increment for a backwards
incompatible change?  In our current tooling this would be hard, but is it what
we should be doing?  Is this the root of the problem?


It seems to me that this is basically microversions except that it gives you the 
added knowledge that a backwards incompatible change has occurred.  I'm not 
quite clear how that makes any difference though.


For applications linking against libraries, the major version implies a 
dependency--the application requires that specific major version of the library, 
and a minor version at least as good as what it was built against.  How would 
that translate to a REST API?  Would the client code need to special-case every 
major version that they plan on supporting?  What about minor versions that add 
functionality--if we special-case those as well then we're basically back to 
microversions.


Chris

__
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

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Igor Kalnitsky]

Hi guys,

@Sergii, you didn't pay attention. Evgeny Li has provided a ticket to
fix it [1].

@Sheena, fuel_plugins_builder isn't associated with Fuel releases.
Here's a list of all versions:

fuel-plugin-builder 2.0.4
fuel-plugin-builder 2.0.3
fuel-plugin-builder 2.0.2
fuel-plugin-builder 2.0.1
fuel-plugin-builder 2.0.0
fuel-plugin-builder 1.0.2
fuel-plugin-builder 1.0.1

I can push tags for them.

Thanks,
Igor

[1] https://bugs.launchpad.net/fuel/+bug/1479785

On Thu, Jul 30, 2015 at 5:54 PM, Sheena Gregson  wrote:
> I would imagine we would want tags for any releases that have plugins
> associated, or we are planning to have plugins associated (so, 6.0, 6.1,
> 7.0).
>
> -Original Message-
> From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com]
> Sent: Thursday, July 30, 2015 9:46 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
>
> Hi Sheena,
>
> Sure, I can do it. Should I push tag only for last release or for all
> releases that are available on PyPI?
>
> Thanks,
> Igor
>
> On Thu, Jul 30, 2015 at 5:29 PM, Sheena Gregson 
> wrote:
>> So the only cores are Igor and Evgeniy?  Can one of you add tags for
>> the new release versions?
>>
>>
>>
>> From: Sebastian Kalinowski [mailto:skalinow...@mirantis.com]
>> Sent: Thursday, July 30, 2015 8:02 AM
>>
>>
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
>>
>>
>>
>>
>>
>>
>>
>> 2015-07-30 14:50 GMT+02:00 Evgeniy L :
>>
>> Hi Sheena,
>>
>>
>>
>> Created ticket to change the structure of the directories [1].
>>
>> And as far as I know any core can push tags into the repository,
>>
>> Sebastian, Igor and I.
>>
>>
>>
>> One correction: I'm not a core in fuel-plugins ;)
>>
>>
>>
>>
>>
>> [1] https://bugs.launchpad.net/fuel/+bug/1479785
>>
>>
>>
>> On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson
>> 
>> wrote:
>>
>> Evgeniy –
>>
>>
>>
>> For the items which you have listed actions, who should be responsible
>> for next steps?
>>
>>
>>
>> Sheena
>>
>>
>>
>> From: Evgeniy L [mailto:e...@mirantis.com]
>> Sent: Tuesday, July 28, 2015 11:54 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
>>
>>
>>
>> Hi Sergii, thank you for feedback,
>>
>>
>>
 c. There is no documentation how to install fpb from github master
 branch. It's very useful for developers who want to use latest
 version. We should add something
>>
>>
>>
>> We had a documentation, but removed it because the newer fpb was
>> released,
>>
>> probably we should add this information permanently [1].
>>
>>
>>
 a. We are doing the same mistake putting all things into one basket.
 There should be 2 repositories. One for examples and one for fpb.
 What's the goal of keeping fpb in directory and examples on top?
>>
>>
>>
>> These plugins are the data which are required for integration testing,
>>
>> we test that plugin build is not broken, which we run when patch gets
>>
>> published. I see nothing wrong with having the data for integration
>> testing
>>
>> in the same repository with product which should be tested.
>>
>> Also in previous release we *removed* all the plugins which are not
>>
>> related to the builder itself, lbaas and glusterfs.
>>
>>
>>
 This breaks a couple of things
>>
>>
>>
>> Having data for testing in the repository doesn't break anything.
>>
>>
>>
 b. I cannot build fpm with simple
>>
>>
>>
>> That is a good point, we should move code from fuel_plugin_builder
>> directory
>>
>> on top level, and move data for testing into examples directory.
>>
>>
>>
 c. There is no tags as I can see only stable/6.0
>>
>>
>>
>> Correct, tags should be added.
>>
>>
>>
 d. There are no tests to improve code quality pep8 flask8, code
 coverage
>>
>>
>>
>> That is not true, there are more then one hundreds unit tests which we
>> run
>>
>> for each patch with python 2.6 and python 2.7, also there are
>> integration tests
>>
>> which check that for each patch we don't break validation and that we
>> can
>>
>> build plugins for previous versions. Plus there are functional tests
>> which are
>>
>> written by fuel-qa team, those tests check that we perform deployment
>>
>> with plugins and required functionality works correctly. Also there
>> *is*
>> pep8
>>
>> check [2].
>>
>>
>>
 e. Repository doesn't follow community standards.
>>
>>
>>
>> I think this issue should be resolved with moving fuel_plugin_builder
>> directory
>>
>> on level higher, if not, please provide more specific description what
>> is wrong.
>>
>>
>>
 3. Setting tab ...
>>
>>
>>
>> Agree.
>>
>>
>>
>> [1]
>> https://wiki.openstack.org/w/index.php?title=Fuel%2FPlugins&diff=78677
>> &oldid=78204
>>
>> [2]
>> https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_bui
>> lder/tox.ini#L17-L21
>>
>>
>>
>> On Tue, Jul 28, 2

Re: [openstack-dev] The proposed "Neutron API extension for packet forwarding" has a lot of duplication to the Neutron SFC API

[Armando M.]

On 29 July 2015 at 22:42, Anita Kuno  wrote:

> On 07/29/2015 02:37 PM, Armando M. wrote:
> > Hi,
> >
> > Since I was quoted, I would like to take the blame on behalf on the
> Neutron
> > core reviewer/drivers team for not providing the right guidance to
> resolve
> > the apparent conflict between the two proposals.
> >
> > As some reviewers mentioned, we should really strive to catch two birds
> > with one stone, and ensure that, if at all possible, the same API can
> > address both use cases presented. In this case, it sounds to me that the
> > API proposed by the networking-sfc sub-project is more comprehensive, it
> > has taken the steps to evolve independently from the Neutron core
> platform,
> > and it has been iterated on multiple times. Surely we can spin off (the
> > forwarding engine) from the spin off (the SFC API), but that would feel
> > like an overkill, especially when both have very little code to show for
> > (and everyone knows that code wins in OpenStack).
> >
> > We should have provided Yuji Azama feedback a lot earlier in the process
> > but we didn't. Again, blame me!
> >
> > I think that Sean raised a flag which should be seen as an acknowledgment
> > of a need to reconcile the two efforts; let's move past the blame game
> and
> > the language barriers, and let's figure out how to address Yuji's need
> > within the context of a single effort, without dismissing it. For this
> > reason I am going to suggest we iterate within the networking-sfc
> project,
> > and block change 186663 .
> Let's
> > figure out how the model/API has to evolve to accommodate the proposed
> used
> > need.
> >
> > If you disagree, please raise your concern on the patch in review itself.
> >
> > Cheers,
> > Armando
>
> Hi Armando,
>
> If my attempts to offer some feedback on communication came across as
> blame than I failed in what I was trying to accomplish.


> My goal was and is to try to illustrate the point that competition and
> collaboration are two separate directions.
>
> While some folks come from a competitive background, I hold the vision
> of OpenStack as a collaborative experience. Some folks many need more
> time than others to understand and digest the differences in behaviour
> associated with the two styles of operating.
>
> I appreciate your email, Armando. At the very least it sets a good
> example for others who many be new to collaboration to follow.
>
> As always, it is a pleasure to work with you Armax,
> Anita.


My point was simply to encourage the people involved in both efforts to
take action after the discussion. The resolution of using one API over the
other did not translate into a patch in any of our repos to capture the
conclusion, at least not until now anyway, and without that, any
back-and-forth is moot.

That said, I think it's important that you keep us honest along our journey
:)

Thank you!


>
> >
> > On 28 July 2015 at 15:01, Sean M. Collins  wrote:
> >
> >> All,
> >>
> >> My suggestion was as follows:
> >>
> >>>  I'd say maybe an e-mail to the ML, with the results of this
> >> meeting, and say that we want to try and converge where
> >>> there is commonality
> >>
> >> I think there is overlap between the two APIs. Let's keep collaborating
> >> on both the networking-sfc and packet forwarding APIs, to see where we
> >> have commonality. I think Cathy's initial e-mail may have ruffled
> >> feathers - and I'd like to smooth them out again. I think the statement
> >> "we only need one API" is far too premature.
> >>
> >> Let's play nice with the other API proposals, yes?
> >>
> >>
> >> --
> >> Sean M. Collins
> >>
> >>
> __
> >> 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 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 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 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

Re: [openstack-dev] [ironic] baremetal server boot failing at iSCSI/tgtd

[Devananda van der Veen]

Hi Vikas,

It looks like the iscsi deploy process wasn't able to attach to the node.
This could be a network issue.

Also, what kernel and ramdisk are you using for the deploy step? Did you
download one, or build it with disk-image-builder? cirros is only suitable
for the instance image, not the deploy.

Regards,
-Deva
On Jul 29, 2015 5:56 PM, "Vikas Choudhary" 
wrote:

> Hi,
> I am trying to boot an instance using pxe deployment process.I am using
> cirros-0.3.4-x86_64-uec image to boot the baremetal server VM.ramdisk and
> kernel images are being deployed successfully , but at kernel
> initialization time its getting stuck there.In console logs I can see that
> tgtd daemon is failing.
>
> CONSOLE LOGS:
> Jul 29 23:17:18 (none) daemon.warn tgtd: tgtd logger started, pid:219
> debug:0^M
> waiting for tgtd socket...found^M
> Jul 29 23:17:19 (none) daemon.err tgtd: iser_ib_init(3351) Failed to
> initialize RDMA; load kernel modules?^M
> Jul 29 23:17:19 (none) daemon.err tgtd: work_timer_start(150) use signal
> based scheduler^M
> Jul 29 23:17:19 (none) daemon.err tgtd: bs_init_signalfd(271) could not
> open backing-store module directory /usr/lib/tgt/backing-store
>
> ir-cond logs:
>
> 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base [-] vendor_passthru
> failed with method pass_deploy_info
> 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base Traceback (most
> recent call last):
> 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base   File
> "/opt/stack/ironic/ironic/drivers/base.py", line 614, in passthru_handler
> 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base return
> func(*args, **kwargs)
> 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base   File
> "/opt/stack/ironic/ironic/conductor/task_manager.py", line 129, in wrapper
> 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base return f(*args,
> **kwargs)
> 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base   File
> "/opt/stack/ironic/ironic/drivers/modules/iscsi_deploy.py", line 815, in
> pass_deploy_info
> 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base
> uuid_dict_returned = continue_deploy(task, **kwargs)
> 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base   File
> "/opt/stack/ironic/ironic/drivers/modules/iscsi_deploy.py", line 392, in
> continue_deploy
> 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base
> _fail_deploy(task, msg)
> 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base   File
> "/opt/stack/ironic/ironic/drivers/modules/iscsi_deploy.py", line 365, in
> _fail_deploy
> 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base raise exception.
> InstanceDeployFailure(msg)
> 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base
> InstanceDeployFailure: Deploy failed for instance 
> 42c3dea0-1f08-44f6-a38a-e6bd16d1212a.
> Error: Unexpected error while running command.
> 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base Command: sudo
> ironic-rootwrap /etc/ironic/rootwrap.conf iscsiadm -m discovery -t st -p
> 50.0.0.10:3260
> 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base Exit code: 4
> 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base Stdout: u''
> 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base Stderr: u'iscsiadm:
> connect to 50.0.0.10 timed out\niscsiadm: connect to 50.0.0.10 timed
> out\niscsiadm: connect to 50.0.0.10 timed out\niscsiadm: connect to
> 50.0.0.10 timed out\niscsiadm: connect to 50.0.0.10 timed out\niscsiadm:
> connect to 50.0.0.10 timed out\niscsiadm: connection login retries
> (reopen_max) 5 exceeded\niscsiadm: Could not perform SendTargets discovery:
> encountered connection failure\n'
> 2015-07-30 04:55:47.095 355 ERROR ironic.drivers.base
> 2015-07-30 04:55:47.217 355 DEBUG ironic.conductor.task_manager [-]
> Successfully released exclusive lock for calling vendor passthru on node
> ac0a1e31-2545-4d26-988a-56134584721e (lock was held 496.37 sec)
> release_resources /opt/stack/ironic/ironic/conductor/task_manager.py:305
>
> I would really appreciate any help/discussion/pointers.Please suggest.
>
> __
> 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 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

Re: [openstack-dev] [kolla] Marking install-from-source as implemented

[Steven Dake (stdake)]

Paul and all,

Thanks for the fantastic work leading this bueprint.  If we can use this
same approach for new Ansible services, I think we would end up with a
development team that is trained in Ansible the same way the dev team is
trained in creating build from source code.

That etherpad is here:

https://etherpad.openstack.org/p/ansibalising-containers


Line 29+ needs folks to assign themselves to the work :)

Regards
-steve


On 7/30/15, 6:35 AM, "Paul Bourke"  wrote:

>Hi Kolla folk,
>
>Just a quick note to say I've marked this bp as implemented. Source
>builds for all key services are merged so I think it's as a time as any.
>Please file separate bugs for subsequent contrib services (any existing
>ones for out for review can stay as is).
>
>Any issues with this let me know, thanks to everyone who helped with
>this bp.
>
>-Paul
>
>__
>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 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

Re: [openstack-dev] how to debug neutron using eclipse pydev?

[Adam Young]

On 07/29/2015 11:42 PM, xueguan...@hotmail.com wrote:

Hi,Assaf
Does PyCharm really works?
i use Pycharm 3.4.1 and  Gevent debugging Enabled,
but i still can not step into the place  i want, pycharm will go to 
thread.py.


I know that with Keystone we needed to run with standard threads, not 
eventlet greenthreads in order to get step by step debugging.


I've been mostly working with RPD, and that has worked well for me. I 
used PyCHarm for a bout a year, but did not renew it, as it doesn't 
really buy me that much when I have to ssh in to a remote machine anyway.



My Write up
http://adam.younglogic.com/2015/02/debugging-openstack-with-rpdb/





- Original Message -
>We need to update that page. I haven't used PyDev in years, I use PyCharm.
>There's an option in PyCharm called 'Enable Gevent debugging' (Gevent is
>a green threads library very similar to eventlet, which is what we use
>in OpenStack). I read that PyDev 3.7+ has support for Gevent debugging
>as well. Can you check if simply enabling that (And not editing any code)
>solves your issue? If so I can update the wiki with your conclusions.



__
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 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

Re: [openstack-dev] [kolla] Mission change suggested by the TC for big tent

[Steven Dake (stdake)]

On 7/29/15, 1:23 PM, "Doug Hellmann"  wrote:

>Excerpts from Steven Dake (stdake)'s message of 2015-07-29 20:07:26 +:
>> Doug Hellman of the TC suggested we change the mission statement of
>>Kolla to be a little less specific.  The new mission statement I
>>submitted in the review is here Is basically cutting off the last part
>>of the mission statement sentence:
>> 
>> https://review.openstack.org/#/c/206789/
>> 
>> If your a Kolla core eviewer, please vote ­1 (indicating you are a core
>>reviewer in the review) if you dislike this change and think we should
>>strive to keep our mission unchanged.  If you don¹t really have a strong
>>preference, please abstain from voting as to not add non-useful
>>information to the review.  Our core team knows what our true mission is
>>and I don¹t think Doug¹s wording changes the mission significantly.
>
>My intent is not to change it at all, but to remove the "marketing
>fluff", to be consistent with the nature of the missions described
>by most of the other projects.  By all means, hold to those other
>ideals and goals, but in the project list we want the mission to
>say what you're doing as clearly and concisely as possible.
>
>Doug

Doug,

Its all good, I think the change you suggested simplifies the statement
without changing the intent.  We can still do all those other things as
you just indicated if we choose to.

I still want to give the core reviewer team an opportunity to vote on the
change which is why I set the short deadline of Aug 3rd to vote -1 (and
act as a veto vote) which would trigger irc meetings to rework the mission
statement.

Thanks for the good feedback, I actually think the modified mission
statement is faster to say which is always a good thing :)

Regards
-steve

>
>> 
>> I¹ll keep the schedule open until August 3rd and ask the TC to hold off
>>on approving the submitted mission until the core team has not weighed
>>in with a ­1 vote.  A vote of ­1 will count as a veto from the core
>>reviewer team, and we will have to have some kind of super-brainstorming
>>session like we did before to simplify the Kolla mission statement to
>>something the TC would accept.
>> 
>> Regards
>> -steve
>
>__
>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 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

Re: [openstack-dev] [Ironic] Lenovo driver submission requests

[Devananda van der Veen]

Yes, yes, and yes to what has been said already. (Thanks Dmitry, Lucas, and
Jim)

-Devananda
On Jul 30, 2015 7:05 AM, "Jim Rollenhagen"  wrote:

> On Thu, Jul 30, 2015 at 09:27:42AM +0200, Dmitry Tantsur wrote:
> > On 07/30/2015 08:59 AM, Kai KH Huang wrote:
> > >Dear Devananda
> > >
> > >  I'm the development leader of Lenovo Cloud Solution. Lenovo is
> > >planning to contribute its Ironic driver to the OpenStack community. The
> > >Ironic driver developers already registered as OpenStack members and
> > >signed agreement with OpenStack org.
> > >
> > >  Sorry for broadcasting the message, but seems we have issue
> > >sending mails to GMail account from China. Devananda, do you have
> > >alternative mail for follow-up communication? Thanks.
> >
> > Hi!
> >
> > I'm adding [Ironic] tag to your message, so that our mail filters mark
> it as
> > belonging to Ironic.
> >
> > Of course I can't answer for Devananda, but I think you can go ahead with
> > proposing a spec [1] for your driver, see some already approved spec
> (e.g.
> > [2] and [3]) for example. Drop by our IRC channel #openstack-ironic on
> > Freenode if you have urgent questions to the team, or post here with
> > [Ironic] tag.
>
> Just to add to this, there shouldn't be much reason to email the PTL
> (Devananda) directly about your contributions. This discussion should be
> done in the open, on this mailing list, as that is the OpenStack way[0]. :)
>
> [0] https://wiki.openstack.org/wiki/Open
>
> // jim
>
> __
> 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 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

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

[Rich Megginson]

On 07/30/2015 08:53 AM, Matthew Mosesohn wrote:

Hi Rich,

Sorry, I meant to link [0] to https://bugs.launchpad.net/keystone/+bug/1470635
More responses inline.


On Thu, Jul 30, 2015 at 5:38 PM, Rich Megginson  wrote:

There is a patch upstream[1] that enables V3 service endpoint
creation, but v2.0 users/clients will not see these endpoints.


Right.  I'm not sure what the problem is - v3 clients can see the endpoints
created with v2.


But not vice versa.


But you said "We are using Keystone v2.0 API everywhere currently." - Are
you trying to move to use v3?

Not yet.


I'm still not sure what the problem is.  Are you trying to move to use v3
for auth, and use v3 resources like domains?

No. Avoiding that is better for now.

Option 1: Keep v2.0 API data in openrc and hack v3 keystone providers,
updating ENV with 2 vars:
OS_IDENTITY_API_VERSION=3
OS_AUTH_URL=$(echo "$OLD_OS_AUTH_URL" | sed -e s'/v2.0/v3/')
or their equivalent in command line parameters


I don't understand.  When you say "v3 keystone providers" are you talking
about the puppet-keystone openstack.rb providers?  If so, they already do
something similar to the above.

Yes, the puppet-keystone openstack.rb providers. Almost, except they don't
update the identity_api_version. It just passes the version from ENV
or $HOME/openrc

https://github.com/openstack/puppet-openstacklib/blob/master/lib/puppet/provider/openstack/credentials.rb


Ok, I see.  The intention of that code is that, if you specify something 
in ENV/openrc, it will override the default settings in the provider.


What if the puppet-keystone openstack providers did not allow you to 
override the api version/url version with ENV/openrc?  Would that solve 
the problem?





Option 2: Update to v3 Identity API for all services and accept the
unmerged patch[1]. This route requires the most disruptive changes
because of [0] and I would like to avoid this.


I don't understand why you need [1] which makes keystone_endpoint use the v3
api.  v3 clients can see endpoints created with the v2 api.

Updating all clients to v3 is more effort at this point and v3
keystone is not targeted for Fuel 7.0.


Option 3: Revert puppet-keystone to version 5.1.0 which is before v3
became mandatory.


I'd like to see what is possible with Option 1 because it should be
possible to use the existing providers in puppet-keystone master
without too many hoops to make them all work cleanly. I'd really
prefer being able to provide all these parameters to the keystone
provider, rather than relying on the /root/openrc file or exporting
shell vars, but getting this issue unstuck is really the most
important.


I'm still not sure what the issue is, what you are prevented from doing.

The issue, concisely, is creating service_endpoints with v2.0 API and
other keystone resources with v3 API using one /root/openrc file.

__
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 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

Re: [openstack-dev] [fuel] Meeting 7/30

[Mike Scherbakov]

We need to discuss:
- feature freeze exceptions, current status
- librarian
- overall bugs status
- change SCF date to focus on most important bugs
- bugs stalled in "in progress" state

Folks - please add your items to the agenda.

On Thu, Jul 30, 2015 at 7:54 AM Andrew Woodward  wrote:

> Please note the IRC meeting is scheduled for 16:00 UTC (about 1 hour from
> now) in #openstack-meeting-alt
>
> Please review meeting agenda and update if there is something you wish to
> discuss.
>
> https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
>
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
> __
> 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
>
-- 
Mike Scherbakov
#mihgen
__
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

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Sheena Gregson]

I would imagine we would want tags for any releases that have plugins
associated, or we are planning to have plugins associated (so, 6.0, 6.1,
7.0).

-Original Message-
From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com]
Sent: Thursday, July 30, 2015 9:46 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback

Hi Sheena,

Sure, I can do it. Should I push tag only for last release or for all
releases that are available on PyPI?

Thanks,
Igor

On Thu, Jul 30, 2015 at 5:29 PM, Sheena Gregson 
wrote:
> So the only cores are Igor and Evgeniy?  Can one of you add tags for
> the new release versions?
>
>
>
> From: Sebastian Kalinowski [mailto:skalinow...@mirantis.com]
> Sent: Thursday, July 30, 2015 8:02 AM
>
>
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
>
>
>
>
>
>
>
> 2015-07-30 14:50 GMT+02:00 Evgeniy L :
>
> Hi Sheena,
>
>
>
> Created ticket to change the structure of the directories [1].
>
> And as far as I know any core can push tags into the repository,
>
> Sebastian, Igor and I.
>
>
>
> One correction: I'm not a core in fuel-plugins ;)
>
>
>
>
>
> [1] https://bugs.launchpad.net/fuel/+bug/1479785
>
>
>
> On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson
> 
> wrote:
>
> Evgeniy –
>
>
>
> For the items which you have listed actions, who should be responsible
> for next steps?
>
>
>
> Sheena
>
>
>
> From: Evgeniy L [mailto:e...@mirantis.com]
> Sent: Tuesday, July 28, 2015 11:54 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
>
>
>
> Hi Sergii, thank you for feedback,
>
>
>
>>> c. There is no documentation how to install fpb from github master
>>> branch. It's very useful for developers who want to use latest
>>> version. We should add something
>
>
>
> We had a documentation, but removed it because the newer fpb was
> released,
>
> probably we should add this information permanently [1].
>
>
>
>>> a. We are doing the same mistake putting all things into one basket.
>>> There should be 2 repositories. One for examples and one for fpb.
>>> What's the goal of keeping fpb in directory and examples on top?
>
>
>
> These plugins are the data which are required for integration testing,
>
> we test that plugin build is not broken, which we run when patch gets
>
> published. I see nothing wrong with having the data for integration
> testing
>
> in the same repository with product which should be tested.
>
> Also in previous release we *removed* all the plugins which are not
>
> related to the builder itself, lbaas and glusterfs.
>
>
>
>>> This breaks a couple of things
>
>
>
> Having data for testing in the repository doesn't break anything.
>
>
>
>>> b. I cannot build fpm with simple
>
>
>
> That is a good point, we should move code from fuel_plugin_builder
> directory
>
> on top level, and move data for testing into examples directory.
>
>
>
>>> c. There is no tags as I can see only stable/6.0
>
>
>
> Correct, tags should be added.
>
>
>
>>> d. There are no tests to improve code quality pep8 flask8, code
>>> coverage
>
>
>
> That is not true, there are more then one hundreds unit tests which we
> run
>
> for each patch with python 2.6 and python 2.7, also there are
> integration tests
>
> which check that for each patch we don't break validation and that we
> can
>
> build plugins for previous versions. Plus there are functional tests
> which are
>
> written by fuel-qa team, those tests check that we perform deployment
>
> with plugins and required functionality works correctly. Also there
> *is*
> pep8
>
> check [2].
>
>
>
>>> e. Repository doesn't follow community standards.
>
>
>
> I think this issue should be resolved with moving fuel_plugin_builder
> directory
>
> on level higher, if not, please provide more specific description what
> is wrong.
>
>
>
>>> 3. Setting tab ...
>
>
>
> Agree.
>
>
>
> [1]
> https://wiki.openstack.org/w/index.php?title=Fuel%2FPlugins&diff=78677
> &oldid=78204
>
> [2]
> https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_bui
> lder/tox.ini#L17-L21
>
>
>
> On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk
>  wrote:
>
> Hi,
>
> I have started digging into plugins recently. There are many positive
> things though I would like to point to some problem areas
>
> 1. Documentation
>
> a. It doesn't include the features of 7.0. There are many outstanding
> features, though I needed to ping the developers to ask how these
> features work. It means that it's almost impossible to develop plugins
> for upcoming releases. The external developer needs to wait for
> documentation so it creates a lag between release and plugin release.
>
> b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be
> extended to 14.04. Also we don't need to add PATCH version as 12.04.2
> is equivalent to
> 12.04
>
> c. There is no documentation how to install fp

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

[Matthew Mosesohn]

Hi Rich,

Sorry, I meant to link [0] to https://bugs.launchpad.net/keystone/+bug/1470635
More responses inline.


On Thu, Jul 30, 2015 at 5:38 PM, Rich Megginson  wrote:
>> There is a patch upstream[1] that enables V3 service endpoint
>> creation, but v2.0 users/clients will not see these endpoints.
>
>
> Right.  I'm not sure what the problem is - v3 clients can see the endpoints
> created with v2.
>
But not vice versa.

> But you said "We are using Keystone v2.0 API everywhere currently." - Are
> you trying to move to use v3?

Not yet.

> I'm still not sure what the problem is.  Are you trying to move to use v3
> for auth, and use v3 resources like domains?

No. Avoiding that is better for now.
>
>>
>> Option 1: Keep v2.0 API data in openrc and hack v3 keystone providers,
>> updating ENV with 2 vars:
>> OS_IDENTITY_API_VERSION=3
>> OS_AUTH_URL=$(echo "$OLD_OS_AUTH_URL" | sed -e s'/v2.0/v3/')
>> or their equivalent in command line parameters
>
>
> I don't understand.  When you say "v3 keystone providers" are you talking
> about the puppet-keystone openstack.rb providers?  If so, they already do
> something similar to the above.
Yes, the puppet-keystone openstack.rb providers. Almost, except they don't
update the identity_api_version. It just passes the version from ENV
or $HOME/openrc

https://github.com/openstack/puppet-openstacklib/blob/master/lib/puppet/provider/openstack/credentials.rb

>
>>
>> Option 2: Update to v3 Identity API for all services and accept the
>> unmerged patch[1]. This route requires the most disruptive changes
>> because of [0] and I would like to avoid this.
>
>
> I don't understand why you need [1] which makes keystone_endpoint use the v3
> api.  v3 clients can see endpoints created with the v2 api.

Updating all clients to v3 is more effort at this point and v3
keystone is not targeted for Fuel 7.0.

>>
>> Option 3: Revert puppet-keystone to version 5.1.0 which is before v3
>> became mandatory.
>>
>>
>> I'd like to see what is possible with Option 1 because it should be
>> possible to use the existing providers in puppet-keystone master
>> without too many hoops to make them all work cleanly. I'd really
>> prefer being able to provide all these parameters to the keystone
>> provider, rather than relying on the /root/openrc file or exporting
>> shell vars, but getting this issue unstuck is really the most
>> important.
>
>
> I'm still not sure what the issue is, what you are prevented from doing.

The issue, concisely, is creating service_endpoints with v2.0 API and
other keystone resources with v3 API using one /root/openrc file.

__
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-dev] [fuel] Meeting 7/30

[Andrew Woodward]

Please note the IRC meeting is scheduled for 16:00 UTC (about 1 hour from
now) in #openstack-meeting-alt

Please review meeting agenda and update if there is something you wish to
discuss.

https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda

-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
__
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

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Sergii Golovatiuk]

Hi,

Please also change the structure of repository. I like using pip install
git+https://

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Thu, Jul 30, 2015 at 4:45 PM, Igor Kalnitsky 
wrote:

> Hi Sheena,
>
> Sure, I can do it. Should I push tag only for last release or for all
> releases that are available on PyPI?
>
> Thanks,
> Igor
>
> On Thu, Jul 30, 2015 at 5:29 PM, Sheena Gregson 
> wrote:
> > So the only cores are Igor and Evgeniy?  Can one of you add tags for the
> new
> > release versions?
> >
> >
> >
> > From: Sebastian Kalinowski [mailto:skalinow...@mirantis.com]
> > Sent: Thursday, July 30, 2015 8:02 AM
> >
> >
> > To: OpenStack Development Mailing List (not for usage questions)
> > 
> > Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
> >
> >
> >
> >
> >
> >
> >
> > 2015-07-30 14:50 GMT+02:00 Evgeniy L :
> >
> > Hi Sheena,
> >
> >
> >
> > Created ticket to change the structure of the directories [1].
> >
> > And as far as I know any core can push tags into the repository,
> >
> > Sebastian, Igor and I.
> >
> >
> >
> > One correction: I'm not a core in fuel-plugins ;)
> >
> >
> >
> >
> >
> > [1] https://bugs.launchpad.net/fuel/+bug/1479785
> >
> >
> >
> > On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson 
> > wrote:
> >
> > Evgeniy –
> >
> >
> >
> > For the items which you have listed actions, who should be responsible
> for
> > next steps?
> >
> >
> >
> > Sheena
> >
> >
> >
> > From: Evgeniy L [mailto:e...@mirantis.com]
> > Sent: Tuesday, July 28, 2015 11:54 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > 
> > Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
> >
> >
> >
> > Hi Sergii, thank you for feedback,
> >
> >
> >
> >>> c. There is no documentation how to install fpb from github master
> >>> branch. It's very useful for developers who want to use latest
> version. We
> >>> should add something
> >
> >
> >
> > We had a documentation, but removed it because the newer fpb was
> released,
> >
> > probably we should add this information permanently [1].
> >
> >
> >
> >>> a. We are doing the same mistake putting all things into one basket.
> >>> There should be 2 repositories. One for examples and one for fpb.
> What's the
> >>> goal of keeping fpb in directory and examples on top?
> >
> >
> >
> > These plugins are the data which are required for integration testing,
> >
> > we test that plugin build is not broken, which we run when patch gets
> >
> > published. I see nothing wrong with having the data for integration
> testing
> >
> > in the same repository with product which should be tested.
> >
> > Also in previous release we *removed* all the plugins which are not
> >
> > related to the builder itself, lbaas and glusterfs.
> >
> >
> >
> >>> This breaks a couple of things
> >
> >
> >
> > Having data for testing in the repository doesn't break anything.
> >
> >
> >
> >>> b. I cannot build fpm with simple
> >
> >
> >
> > That is a good point, we should move code from fuel_plugin_builder
> directory
> >
> > on top level, and move data for testing into examples directory.
> >
> >
> >
> >>> c. There is no tags as I can see only stable/6.0
> >
> >
> >
> > Correct, tags should be added.
> >
> >
> >
> >>> d. There are no tests to improve code quality pep8 flask8, code
> coverage
> >
> >
> >
> > That is not true, there are more then one hundreds unit tests which we
> run
> >
> > for each patch with python 2.6 and python 2.7, also there are integration
> > tests
> >
> > which check that for each patch we don't break validation and that we can
> >
> > build plugins for previous versions. Plus there are functional tests
> which
> > are
> >
> > written by fuel-qa team, those tests check that we perform deployment
> >
> > with plugins and required functionality works correctly. Also there *is*
> > pep8
> >
> > check [2].
> >
> >
> >
> >>> e. Repository doesn't follow community standards.
> >
> >
> >
> > I think this issue should be resolved with moving fuel_plugin_builder
> > directory
> >
> > on level higher, if not, please provide more specific description what is
> > wrong.
> >
> >
> >
> >>> 3. Setting tab ...
> >
> >
> >
> > Agree.
> >
> >
> >
> > [1]
> >
> https://wiki.openstack.org/w/index.php?title=Fuel%2FPlugins&diff=78677&oldid=78204
> >
> > [2]
> >
> https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/tox.ini#L17-L21
> >
> >
> >
> > On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk
> >  wrote:
> >
> > Hi,
> >
> > I have started digging into plugins recently. There are many positive
> things
> > though I would like to point to some problem areas
> >
> > 1. Documentation
> >
> > a. It doesn't include the features of 7.0. There are many outstanding
> > features, though I needed to ping the developers to ask how these
> features
> > work. It means that it's almost impossible to develop plugins for
> upcoming
> > releases. The external developer needs to wait for documentation so it
> > creates a lag between release a

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Igor Kalnitsky]

Hi Sheena,

Sure, I can do it. Should I push tag only for last release or for all
releases that are available on PyPI?

Thanks,
Igor

On Thu, Jul 30, 2015 at 5:29 PM, Sheena Gregson  wrote:
> So the only cores are Igor and Evgeniy?  Can one of you add tags for the new
> release versions?
>
>
>
> From: Sebastian Kalinowski [mailto:skalinow...@mirantis.com]
> Sent: Thursday, July 30, 2015 8:02 AM
>
>
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
>
>
>
>
>
>
>
> 2015-07-30 14:50 GMT+02:00 Evgeniy L :
>
> Hi Sheena,
>
>
>
> Created ticket to change the structure of the directories [1].
>
> And as far as I know any core can push tags into the repository,
>
> Sebastian, Igor and I.
>
>
>
> One correction: I'm not a core in fuel-plugins ;)
>
>
>
>
>
> [1] https://bugs.launchpad.net/fuel/+bug/1479785
>
>
>
> On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson 
> wrote:
>
> Evgeniy –
>
>
>
> For the items which you have listed actions, who should be responsible for
> next steps?
>
>
>
> Sheena
>
>
>
> From: Evgeniy L [mailto:e...@mirantis.com]
> Sent: Tuesday, July 28, 2015 11:54 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
>
>
>
> Hi Sergii, thank you for feedback,
>
>
>
>>> c. There is no documentation how to install fpb from github master
>>> branch. It's very useful for developers who want to use latest version. We
>>> should add something
>
>
>
> We had a documentation, but removed it because the newer fpb was released,
>
> probably we should add this information permanently [1].
>
>
>
>>> a. We are doing the same mistake putting all things into one basket.
>>> There should be 2 repositories. One for examples and one for fpb. What's the
>>> goal of keeping fpb in directory and examples on top?
>
>
>
> These plugins are the data which are required for integration testing,
>
> we test that plugin build is not broken, which we run when patch gets
>
> published. I see nothing wrong with having the data for integration testing
>
> in the same repository with product which should be tested.
>
> Also in previous release we *removed* all the plugins which are not
>
> related to the builder itself, lbaas and glusterfs.
>
>
>
>>> This breaks a couple of things
>
>
>
> Having data for testing in the repository doesn't break anything.
>
>
>
>>> b. I cannot build fpm with simple
>
>
>
> That is a good point, we should move code from fuel_plugin_builder directory
>
> on top level, and move data for testing into examples directory.
>
>
>
>>> c. There is no tags as I can see only stable/6.0
>
>
>
> Correct, tags should be added.
>
>
>
>>> d. There are no tests to improve code quality pep8 flask8, code coverage
>
>
>
> That is not true, there are more then one hundreds unit tests which we run
>
> for each patch with python 2.6 and python 2.7, also there are integration
> tests
>
> which check that for each patch we don't break validation and that we can
>
> build plugins for previous versions. Plus there are functional tests which
> are
>
> written by fuel-qa team, those tests check that we perform deployment
>
> with plugins and required functionality works correctly. Also there *is*
> pep8
>
> check [2].
>
>
>
>>> e. Repository doesn't follow community standards.
>
>
>
> I think this issue should be resolved with moving fuel_plugin_builder
> directory
>
> on level higher, if not, please provide more specific description what is
> wrong.
>
>
>
>>> 3. Setting tab ...
>
>
>
> Agree.
>
>
>
> [1]
> https://wiki.openstack.org/w/index.php?title=Fuel%2FPlugins&diff=78677&oldid=78204
>
> [2]
> https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/tox.ini#L17-L21
>
>
>
> On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk
>  wrote:
>
> Hi,
>
> I have started digging into plugins recently. There are many positive things
> though I would like to point to some problem areas
>
> 1. Documentation
>
> a. It doesn't include the features of 7.0. There are many outstanding
> features, though I needed to ping the developers to ask how these features
> work. It means that it's almost impossible to develop plugins for upcoming
> releases. The external developer needs to wait for documentation so it
> creates a lag between release and plugin release.
>
> b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended to
> 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent to
> 12.04
>
> c. There is no documentation how to install fpb from github master branch.
> It's very useful for developers who want to use latest version. We should
> add something
>
> 2. Github repository [2] is messed up
>
> a. We are doing the same mistake putting all things into one basket. There
> should be 2 repositories. One for examples and one for fpb. What's the goal
> of keeping fpb in directory and examples on top? This breaks a couple of
> things
>
> b. I can

Re: [openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

[Rich Megginson]

On 07/30/2015 08:24 AM, Matthew Mosesohn wrote:

Hi all,

It seems that I've reached an impasse with
https://review.openstack.org/#/q/topic:bp/detach-components-from-controllers,n,z
in Keystone with regards to Kilo puppet manifests. One of the
objectives is the ability to deploy Keystone on a separate node from
the controllers.

Here is what we know:

We are using Keystone v2.0 API everywhere currently.

Most Keystone providers for users, services, etc, use V3 API through
openstackclient

Keystone provider for service endpoints is still on V2. This is
because v2.0 clients can't see v3 endpoints. It's "by design" to not
be forward compatible[0].


I don't understand - [0] is a link to an ansible review?


There is a patch upstream[1] that enables V3 service endpoint
creation, but v2.0 users/clients will not see these endpoints.


Right.  I'm not sure what the problem is - v3 clients can see the 
endpoints created with v2.


Note that in Keystone, resources like roles, services, and endpoints are 
_not_ domain scoped, and therefore do not need to use the v3 api to CRUD.




Identity v2 and v3 behavior of openstackclient are vastly different.
There is nothing backward/forward compatible among the two, so it's a
hassle to deal with them in parallel.

openstackclient fails on v3 parameters unless version 3 is explicitly enabled.


But you said "We are using Keystone v2.0 API everywhere currently." - 
Are you trying to move to use v3?




What we can do to go forward?


I'm still not sure what the problem is.  Are you trying to move to use 
v3 for auth, and use v3 resources like domains?




Option 1: Keep v2.0 API data in openrc and hack v3 keystone providers,
updating ENV with 2 vars:
OS_IDENTITY_API_VERSION=3
OS_AUTH_URL=$(echo "$OLD_OS_AUTH_URL" | sed -e s'/v2.0/v3/')
or their equivalent in command line parameters


I don't understand.  When you say "v3 keystone providers" are you 
talking about the puppet-keystone openstack.rb providers?  If so, they 
already do something similar to the above.




Option 2: Update to v3 Identity API for all services and accept the
unmerged patch[1]. This route requires the most disruptive changes
because of [0] and I would like to avoid this.


I don't understand why you need [1] which makes keystone_endpoint use 
the v3 api.  v3 clients can see endpoints created with the v2 api.




Option 3: Revert puppet-keystone to version 5.1.0 which is before v3
became mandatory.


I'd like to see what is possible with Option 1 because it should be
possible to use the existing providers in puppet-keystone master
without too many hoops to make them all work cleanly. I'd really
prefer being able to provide all these parameters to the keystone
provider, rather than relying on the /root/openrc file or exporting
shell vars, but getting this issue unstuck is really the most
important.


I'm still not sure what the issue is, what you are prevented from doing.




[0] https://review.openstack.org/#/c/196943/
[1] https://review.openstack.org/#/c/178456/24

Best Regards,
Matthew Mosesohn

__
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 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

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Sheena Gregson]

So the only cores are Igor and Evgeniy?  Can one of you add tags for the
new release versions?



*From:* Sebastian Kalinowski [mailto:skalinow...@mirantis.com]
*Sent:* Thursday, July 30, 2015 8:02 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel][Plugins] Feedback







2015-07-30 14:50 GMT+02:00 Evgeniy L :

Hi Sheena,



Created ticket to change the structure of the directories [1].

And as far as I know any core can push tags into the repository,

Sebastian, Igor and I.



One correction: I'm not a core in fuel-plugins ;)





[1] https://bugs.launchpad.net/fuel/+bug/1479785



On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson 
wrote:

Evgeniy –



For the items which you have listed actions, who should be responsible for
next steps?



Sheena



*From:* Evgeniy L [mailto:e...@mirantis.com]
*Sent:* Tuesday, July 28, 2015 11:54 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel][Plugins] Feedback



Hi Sergii, thank you for feedback,



>> c. There is no documentation how to install fpb from github master
branch. It's very useful for developers who want to use latest version. We
should add something



We had a documentation, but removed it because the newer fpb was released,

probably we should add this information permanently [1].



>> a. We are doing the same mistake putting all things into one basket.
There should be 2 repositories. One for examples and one for fpb. What's
the goal of keeping fpb in directory and examples on top?



These plugins are the data which are required for integration testing,

we test that plugin build is not broken, which we run when patch gets

published. I see nothing wrong with having the data for integration testing

in the same repository with product which should be tested.

Also in previous release we *removed* all the plugins which are not

related to the builder itself, lbaas and glusterfs.



>> This breaks a couple of things



Having data for testing in the repository doesn't break anything.



>> b. I cannot build fpm with simple



That is a good point, we should move code from fuel_plugin_builder directory

on top level, and move data for testing into examples directory.



>> c. There is no tags as I can see only stable/6.0



Correct, tags should be added.



>> d. There are no tests to improve code quality pep8 flask8, code coverage



That is not true, there are more then one hundreds unit tests which we run

for each patch with python 2.6 and python 2.7, also there are integration
tests

which check that for each patch we don't break validation and that we can

build plugins for previous versions. Plus there are functional tests which
are

written by fuel-qa team, those tests check that we perform deployment

with plugins and required functionality works correctly. Also there *is*
pep8

check [2].



>> e. Repository doesn't follow community standards.



I think this issue should be resolved with moving fuel_plugin_builder
directory

on level higher, if not, please provide more specific description what is
wrong.



>> 3. Setting tab ...



Agree.



[1]
https://wiki.openstack.org/w/index.php?title=Fuel%2FPlugins&diff=78677&oldid=78204

[2]
https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/tox.ini#L17-L21



On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk 
wrote:

Hi,

I have started digging into plugins recently. There are many positive
things though I would like to point to some problem areas

1. Documentation

a. It doesn't include the features of 7.0. There are many outstanding
features, though I needed to ping the developers to ask how these features
work. It means that it's almost impossible to develop plugins for upcoming
releases. The external developer needs to wait for documentation so it
creates a lag between release and plugin release.

b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended
to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent
to 12.04

c. There is no documentation how to install fpb from github master branch.
It's very useful for developers who want to use latest version. We should
add something

2. Github repository [2] is messed up

a. We are doing the same mistake putting all things into one basket. There
should be 2 repositories. One for examples and one for fpb. What's the goal
of keeping fpb in directory and examples on top? This breaks a couple of
things

b. I cannot build fpm with simple

pip install git+https://

Instead I am forced to do

git clone https://

cd fuel-plugins

pip install .



c. There is no tags as I can see only stable/6.0

d. There are no tests to improve code quality pep8 flask8, code coverage

e. Repository doesn't follow community standards.



3. Setting tab

When plugin is installed, it's very hard to find in. In setting tab it's
somewher

Re: [openstack-dev] [fuel] OS_SERVICE_TOKEN usage in Fuel

[Oleksiy Molchanov]

Update from Radoslaw Zarzynski
---

Hi,

I'm afraid that eradication of OS_SERVICE_TOKEN won't be quick
nor painless process due to dependencies. We would need to identify
and fix all applications that requires this auth method.

For example, Ceph RADOS Gateway (radosgw) currently requires [1]
it in order to provide Keystone integration in its S3 API implementation.
We have customers using that in production.

Best regards,
Radoslaw Zarzynski

[1] https://github.com/ceph/ceph/blob/master/src/rgw/rgw_rest_s3.cc#L

On Wed, Jul 29, 2015 at 6:38 PM, Konstantin Danilov 
wrote:

> Would send ceph estimation tomorrow.
> Yet estimation != ETTA
>
> On Wed, Jul 29, 2015 at 12:27 AM, Sergii Golovatiuk
>  wrote:
> > Hi,
> >
> > Let's ask our Ceph developers how much time/resources they need to
> implement
> > such functionality.
> >
> > --
> > Best regards,
> > Sergii Golovatiuk,
> > Skype #golserge
> > IRC #holser
> >
> > On Tue, Jul 28, 2015 at 11:21 PM, Andrew Woodward <
> awoodw...@mirantis.com>
> > wrote:
> >>
> >> It's literally how radosgw goes about verifying users, it has no scheme
> of
> >> using a user or working with auth-tokens. It would have to fixed in the
> >> ceph-radosgw codebase. PKI tokens (which we don't use) rely on this
> less,
> >> but its still used.
> >>
> >> On Tue, Jul 28, 2015 at 2:16 PM Sergii Golovatiuk
> >>  wrote:
> >>>
> >>> Why can't radosgw use own own credentials? If it's technical debt we
> need
> >>> to put it on plate to address in next release.
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>> Sergii Golovatiuk,
> >>> Skype #golserge
> >>> IRC #holser
> >>>
> >>> On Tue, Jul 28, 2015 at 10:21 PM, Andrew Woodward 
> >>> wrote:
> 
>  Keystone authtoken is also used by radosgw to validate users
> 
>  On Tue, Jul 28, 2015 at 10:31 AM Andrew Woodward
>   wrote:
> >
> > IIRC the puppet modules, and even the heat domain create script make
> > use of the token straight from the config file. It not being present
> could
> > cause problems for some of the manifests. We would need to ensure
> that their
> > usage is minimized or removed.
> >
> > On Tue, Jul 28, 2015 at 9:29 AM Sergii Golovatiuk
> >  wrote:
> >>
> >> Hi Oleksiy,
> >>
> >> Good catch. Also OSTF should get endpoints from hiera as some
> plugins
> >> may override the initial deployment settings. There may be cases
> when
> >> keystone is detached by plugin.
> >>
> >> --
> >> Best regards,
> >> Sergii Golovatiuk,
> >> Skype #golserge
> >> IRC #holser
> >>
> >> On Tue, Jul 28, 2015 at 5:26 PM, Oleksiy Molchanov
> >>  wrote:
> >>>
> >>> Hello all,
> >>>
> >>> We need to discuss removal of OS_SERVICE_TOKEN usage in Fuel after
> >>> deployment. This came from
> https://bugs.launchpad.net/fuel/+bug/1430619. I
> >>> guess not all of us have an access to this bug, so to be short:
> >>>
> >>> # A "shared secret" that can be used to bootstrap Keystone.
> >>> # This "token" does not represent a user, and carries no
> >>> # explicit authorization. To disable in production (highly
> >>> # recommended), remove AdminTokenAuthMiddleware from your
> >>> # paste application pipelines (for example, in keystone-
> >>> # paste.ini). (string value)
> >>>
> >>> After removing this and testing we found out that OSTF fails
> because
> >>> it uses admin token.
> >>>
> >>> What do you think if we create ostf user like for workloads, but
> with
> >>> wider permissions?
> >>>
> >>> BR,
> >>> Oleksiy.
> >>>
> >>>
> >>>
> __
> >>> 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 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
> >
> > --
> > --
> > Andrew Woodward
> > Mirantis
> > Fuel Community Ambassador
> > Ceph Community
> >
> >
> __
> > 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
> 
>  --
> 
>  --
> 
>  Andrew Woodward
> 
>  Mirantis
> 
>  Fuel Community Ambassador
> 
>  Ceph Community
> 
> 
> 
> 
> _

Re: [openstack-dev] [nova][cinder] Would anyone from Nova Core be able to join the Cinder mid-cycle meetup?

[D'Angelo, Scott]

We'll have a Google Hangout for the Cinder mid-cycle for virtual attendees and 
will post the links on IRC and the etherpad:
https://etherpad.openstack.org/p/cinder-liberty-midcycle-meetup

We'll make sure we ping mreidem and the Nova channel when we're discussing 
Cinder <-> Nova topics.

-Original Message-
From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] 
Sent: Thursday, July 30, 2015 8:18 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova][cinder] Would anyone from Nova Core be able 
to join the Cinder mid-cycle meetup?



On 7/30/2015 12:31 AM, Anita Kuno wrote:
> On 07/29/2015 10:59 PM, John Garbutt wrote:
>> On 24 July 2015 at 22:49, Jay S. Bryant  
>> wrote:
>>> All,
>>>
>>> I had the opportunity to chat with John Garbutt when he was here in 
>>> Rochester for the Nova mid-cycle meet-up.  We discussed the fact 
>>> that there was much to be gained by improving the communication 
>>> between the Cinder and Nova teams.
>>
>> We do have names written down for CrossProjectLiaisons for other projects.
>> That is helping a little, but I am sure we can refine the idea so its 
>> more effective:
>> https://wiki.openstack.org/wiki/CrossProjectLiaisons#Inter-project_Li
>> aisons
>>
>> The basic ideas would be to get folks who are in the Nova meeting 
>> regularly to jump into the Cinder meeting when required, and someone 
>> else to do the reverse.
>
> What I am finding is that some folks are reluctant to come forward as 
> Liasons initially, despite their possible interest. Some reasons for 
> hesitation might include uncertainty of what responsibilities are 
> understood with the role, uncertainty if there actually is time in the 
> individual's schedule to attend meetings and be available for 
> questions, clarification and follow up, that sort of thing.
>
> I am finding good success by encouraging someone who might consider 
> trying on a cross project hat to do something along those lines: 
> attend a meeting, follow up on an email, engage in a conversation with 
> someone in another project on a specific issue and see how it feels. 
> If it doesn't feel like a good fit, fair enough, thanks for trying it 
> out. If you can help with one thing (example: cells with nova and 
> neutron) great, you don't have to take on everything with the two 
> projects, just focus on one issue and that is most welcome, thank you. 
> (Thanks to mlavelle for volunteering with the cells cross project work 
> here.)
>
> If you have done a few things, shown up for meetings for two projects, 
> followed a particular spec, helped both projects become better 
> informed about how the issue affects those projects, wonderful. Then 
> if you feel like added your name to the wikipage, great, that helps 
> others. But please don't feel that signing up has to be the first 
> step, for some they experience the work for a while before they agree 
> to it publicly, what ever works for you.
>
> Thanks Jay, John, and Paul, glad to see this conversation progress, 
> Anita.
>
>>
>> For specific patches that really important to cinder, it would be 
>> good to advertise them in the usual place for nova:
>> https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
>>
>>> With that idea in mind, it was suggested that the Cinder team open 
>>> an invitation to Nova members to attend our mid-cycle meet-up.  The 
>>> mid-cycle meet-up, of course, is not a secret.  A member of the Nova 
>>> team has always been welcome to join, just hoping that an explicit 
>>> invitation here may spark some interest.  :-)  Note:  John 
>>> considered attending but is unable to do so.
>>
>> So looks like Paul might be there.
>>
>> I can try and join a hangout, if there is something urgent.
>> That approach has big limitations, but happy to try (ideally AM, 
>> given I am in the UK).
>>
>>> The mid-cycle meet-up for Cinder is 8/4 through 8/7 at the HP site 
>>> in Fort Collins, CO .  Friday is an optional code sprint day for 
>>> those who are able to stay that long.  Details about the meet-up can 
>>> be seen on our mid-cycle meetup planning etherpad [1].
>>>
>>> If you are able to join us and help us work through the various 
>>> challenges we are having between Cinder and Nova it would be greatly 
>>> appreciated!
>>
>> +1
>>
>> Thanks,
>> John
>>
>> _
>> _ 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 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
>

If we want a name for nova liaison to cinder, then I can put my name in, I've 
spent enou

[openstack-dev] [neutron] VLAN aware VMs: Current status?

[Kyle Mestery]

I'm sending this email to solicit a response from the owners of the VLAN
aware VMs spec [1] [2]. The spec was merged on June 24, and I haven't seen
any code posted. Given I expect this to take some iterations in review, is
the plan to push code for this sometime soon?

Thanks!
Kyle

[1] https://review.openstack.org/#/c/94612/
[2] https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
__
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-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

[Matthew Mosesohn]

Hi all,

It seems that I've reached an impasse with
https://review.openstack.org/#/q/topic:bp/detach-components-from-controllers,n,z
in Keystone with regards to Kilo puppet manifests. One of the
objectives is the ability to deploy Keystone on a separate node from
the controllers.

Here is what we know:

We are using Keystone v2.0 API everywhere currently.

Most Keystone providers for users, services, etc, use V3 API through
openstackclient

Keystone provider for service endpoints is still on V2. This is
because v2.0 clients can't see v3 endpoints. It's "by design" to not
be forward compatible[0].

There is a patch upstream[1] that enables V3 service endpoint
creation, but v2.0 users/clients will not see these endpoints.

Identity v2 and v3 behavior of openstackclient are vastly different.
There is nothing backward/forward compatible among the two, so it's a
hassle to deal with them in parallel.

openstackclient fails on v3 parameters unless version 3 is explicitly enabled.

What we can do to go forward?

Option 1: Keep v2.0 API data in openrc and hack v3 keystone providers,
updating ENV with 2 vars:
OS_IDENTITY_API_VERSION=3
OS_AUTH_URL=$(echo "$OLD_OS_AUTH_URL" | sed -e s'/v2.0/v3/')
or their equivalent in command line parameters

Option 2: Update to v3 Identity API for all services and accept the
unmerged patch[1]. This route requires the most disruptive changes
because of [0] and I would like to avoid this.

Option 3: Revert puppet-keystone to version 5.1.0 which is before v3
became mandatory.


I'd like to see what is possible with Option 1 because it should be
possible to use the existing providers in puppet-keystone master
without too many hoops to make them all work cleanly. I'd really
prefer being able to provide all these parameters to the keystone
provider, rather than relying on the /root/openrc file or exporting
shell vars, but getting this issue unstuck is really the most
important.


[0] https://review.openstack.org/#/c/196943/
[1] https://review.openstack.org/#/c/178456/24

Best Regards,
Matthew Mosesohn

__
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

Re: [openstack-dev] [fuel][puppet] Fuel Library and upstream modules

[Alex Schultz]

Hey Emilien,

On Wed, Jul 29, 2015 at 5:16 PM, Emilien Macchi  wrote:

>
>
> This is a very good initiative and I'm happy to see that happening. It
> reflects what I was asking in our collaboration request.
>
> Though I have one suggestion for "Custom Upstream Module Changes" section.
> I suggest you:
>
> 1/ first submit the change in the upstream module
> 2/ cherry-pick the commit in Fuel custom branch
> 3/ keep track of upstream patch (address reviews, etc), and establish a
> sort of scoring to evaluate the debt [1] between downstream (Fuel) and
> upstream (OpenStack). It will make sure a maximum of code is upstream
> and downstream patches won't be forgotten.
> 4/ when an upstream patch is merged, drop the cherry-pick by rebasing.
>
>
Thanks, I have updated the page to reference using the cherry-pick option.
I think this sounds better than what was there previously.



> This is the workflow I try to push at Red Hat (in RDO) and to me, this
> is the way to go for having Puppet modules the closest as possible from
> upstream with the freedom to have custom patches downstream.
>
> Best,
>
> [1] https://github.com/redhat-cip/debtor
> --
> Emilien Macchi
>
>
> __
> 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
>
>

Thanks,
-Alex
__
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

Re: [openstack-dev] [Ironic] Lenovo driver submission requests

[Jim Rollenhagen]

On Thu, Jul 30, 2015 at 09:27:42AM +0200, Dmitry Tantsur wrote:
> On 07/30/2015 08:59 AM, Kai KH Huang wrote:
> >Dear Devananda
> >
> >  I'm the development leader of Lenovo Cloud Solution. Lenovo is
> >planning to contribute its Ironic driver to the OpenStack community. The
> >Ironic driver developers already registered as OpenStack members and
> >signed agreement with OpenStack org.
> >
> >  Sorry for broadcasting the message, but seems we have issue
> >sending mails to GMail account from China. Devananda, do you have
> >alternative mail for follow-up communication? Thanks.
> 
> Hi!
> 
> I'm adding [Ironic] tag to your message, so that our mail filters mark it as
> belonging to Ironic.
> 
> Of course I can't answer for Devananda, but I think you can go ahead with
> proposing a spec [1] for your driver, see some already approved spec (e.g.
> [2] and [3]) for example. Drop by our IRC channel #openstack-ironic on
> Freenode if you have urgent questions to the team, or post here with
> [Ironic] tag.

Just to add to this, there shouldn't be much reason to email the PTL
(Devananda) directly about your contributions. This discussion should be
done in the open, on this mailing list, as that is the OpenStack way[0]. :)

[0] https://wiki.openstack.org/wiki/Open

// jim

__
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-dev] [kolla] Marking install-from-source as implemented

[Paul Bourke]

Hi Kolla folk,

Just a quick note to say I've marked this bp as implemented. Source 
builds for all key services are merged so I think it's as a time as any. 
Please file separate bugs for subsequent contrib services (any existing 
ones for out for review can stay as is).


Any issues with this let me know, thanks to everyone who helped with 
this bp.


-Paul

__
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

Re: [openstack-dev] [fuel][puppet] Fuel Library and upstream modules

[Clayton O'Neill]

Emilien, debtor looks like an interesting tool, thanks for the link.

As far as tracking upstream branches from local forks and carrying local
patches, we've had good luck with using the git-upstream tool on stack
forge: https://github.com/stackforge/git-upstream

It allows you to merge in upstream changes on a regular basis and will
automatically drop local changes if there is a matching Change-Id field in
the upstream branch.  It also allows you to manually tag specific changes
to drop.  We have this setup to run as a regular job and the merge commit
for the changes gets pushed to our internal Gerrit instance for review and
all our normal CI tools run against that so we can gauge the impact of the
merge.



On Wed, Jul 29, 2015 at 6:16 PM, Emilien Macchi  wrote:

>
>
> On 07/29/2015 03:48 PM, Alex Schultz wrote:
> > Hello everyone,
> >
> > I have put together a wiki describing the proposed interactions between
> > fuel-library and upstream modules based on previous talks around
> > librarian-puppet[0].  Please take some time to
> > review https://wiki.openstack.org/wiki/Fuel/Library_and_Upstream_Modules
> .
> > This page provides a brief history of this change, details of the
> > changes, best practices, and workflows for dealing with upstream modules.
> >
> > I have updated this page based on the feedback previously solicited
> > around my suggestion to use librarian-puppet to manage the inclusion of
> > upstream modules into fuel-library. During the implementation, we found
> > that packaging librarian-puppet and the dependency management became
> > burdensome. As a substitute, we have packaged librarian-puppet-simple
> > and will only be using git repository references for inclusion of
> > upstream modules.  Also based on our build requirements, we are also
> > leveraging a fuel-infra mirror of upstream repositories to allow for
> > local builds and CI to not have to fetch modules continuously from
> > upstream github repositories.
> >
> > I have also taken the time to update the proposed patches[1] with the
> > librarian-puppet-simple configurations so they they are ready to merge
> > if there is an agreement on this process.
> >
> > Thanks,
> > -Alex
> >
> > [0]
> http://lists.openstack.org/pipermail/openstack-dev/2015-June/067806.html
> > [1]
> https://review.openstack.org/#/q/topic:bp/fuel-puppet-librarian+project:stackforge/fuel-library,n,z
> >
>
> This is a very good initiative and I'm happy to see that happening. It
> reflects what I was asking in our collaboration request.
>
> Though I have one suggestion for "Custom Upstream Module Changes" section.
> I suggest you:
>
> 1/ first submit the change in the upstream module
> 2/ cherry-pick the commit in Fuel custom branch
> 3/ keep track of upstream patch (address reviews, etc), and establish a
> sort of scoring to evaluate the debt [1] between downstream (Fuel) and
> upstream (OpenStack). It will make sure a maximum of code is upstream
> and downstream patches won't be forgotten.
> 4/ when an upstream patch is merged, drop the cherry-pick by rebasing.
>
> This is the workflow I try to push at Red Hat (in RDO) and to me, this
> is the way to go for having Puppet modules the closest as possible from
> upstream with the freedom to have custom patches downstream.
>
> Best,
>
> [1] https://github.com/redhat-cip/debtor
> --
> Emilien Macchi
>
>
> __
> 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 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

Re: [openstack-dev] [all][infra] CI System is broken

[Jeremy Stanley]

On 2015-07-30 10:19:20 +0200 (+0200), Andreas Jaeger wrote:
> Joshua just restarted Zuul and is currently requeueing the jobs
> that were in the system.
[...]

Also we've got some additional debugging added prior to this most
recent restart which should assist in narrowing down the cause
if/when it happens again.
-- 
Jeremy Stanley

__
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

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Sebastian Kalinowski]

2015-07-30 14:50 GMT+02:00 Evgeniy L :

> Hi Sheena,
>
> Created ticket to change the structure of the directories [1].
> And as far as I know any core can push tags into the repository,
> Sebastian, Igor and I.
>

One correction: I'm not a core in fuel-plugins ;)


>
> [1] https://bugs.launchpad.net/fuel/+bug/1479785
>
> On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson 
> wrote:
>
>> Evgeniy –
>>
>>
>>
>> For the items which you have listed actions, who should be responsible
>> for next steps?
>>
>>
>>
>> Sheena
>>
>>
>>
>> *From:* Evgeniy L [mailto:e...@mirantis.com]
>> *Sent:* Tuesday, July 28, 2015 11:54 AM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>
>> *Subject:* Re: [openstack-dev] [Fuel][Plugins] Feedback
>>
>>
>>
>> Hi Sergii, thank you for feedback,
>>
>>
>>
>> >> c. There is no documentation how to install fpb from github master
>> branch. It's very useful for developers who want to use latest version. We
>> should add something
>>
>>
>>
>> We had a documentation, but removed it because the newer fpb was released,
>>
>> probably we should add this information permanently [1].
>>
>>
>>
>> >> a. We are doing the same mistake putting all things into one basket.
>> There should be 2 repositories. One for examples and one for fpb. What's
>> the goal of keeping fpb in directory and examples on top?
>>
>>
>>
>> These plugins are the data which are required for integration testing,
>>
>> we test that plugin build is not broken, which we run when patch gets
>>
>> published. I see nothing wrong with having the data for integration
>> testing
>>
>> in the same repository with product which should be tested.
>>
>> Also in previous release we *removed* all the plugins which are not
>>
>> related to the builder itself, lbaas and glusterfs.
>>
>>
>>
>> >> This breaks a couple of things
>>
>>
>>
>> Having data for testing in the repository doesn't break anything.
>>
>>
>>
>> >> b. I cannot build fpm with simple
>>
>>
>>
>> That is a good point, we should move code from fuel_plugin_builder
>> directory
>>
>> on top level, and move data for testing into examples directory.
>>
>>
>>
>> >> c. There is no tags as I can see only stable/6.0
>>
>>
>>
>> Correct, tags should be added.
>>
>>
>>
>> >> d. There are no tests to improve code quality pep8 flask8, code
>> coverage
>>
>>
>>
>> That is not true, there are more then one hundreds unit tests which we run
>>
>> for each patch with python 2.6 and python 2.7, also there are integration
>> tests
>>
>> which check that for each patch we don't break validation and that we can
>>
>> build plugins for previous versions. Plus there are functional tests
>> which are
>>
>> written by fuel-qa team, those tests check that we perform deployment
>>
>> with plugins and required functionality works correctly. Also there *is*
>> pep8
>>
>> check [2].
>>
>>
>>
>> >> e. Repository doesn't follow community standards.
>>
>>
>>
>> I think this issue should be resolved with moving fuel_plugin_builder
>> directory
>>
>> on level higher, if not, please provide more specific description what is
>> wrong.
>>
>>
>>
>> >> 3. Setting tab ...
>>
>>
>>
>> Agree.
>>
>>
>>
>> [1]
>> https://wiki.openstack.org/w/index.php?title=Fuel%2FPlugins&diff=78677&oldid=78204
>>
>> [2]
>> https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/tox.ini#L17-L21
>>
>>
>>
>> On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk <
>> sgolovat...@mirantis.com> wrote:
>>
>> Hi,
>>
>> I have started digging into plugins recently. There are many positive
>> things though I would like to point to some problem areas
>>
>> 1. Documentation
>>
>> a. It doesn't include the features of 7.0. There are many outstanding
>> features, though I needed to ping the developers to ask how these features
>> work. It means that it's almost impossible to develop plugins for upcoming
>> releases. The external developer needs to wait for documentation so it
>> creates a lag between release and plugin release.
>>
>> b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended
>> to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent
>> to 12.04
>>
>> c. There is no documentation how to install fpb from github master
>> branch. It's very useful for developers who want to use latest version. We
>> should add something
>>
>> 2. Github repository [2] is messed up
>>
>> a. We are doing the same mistake putting all things into one basket.
>> There should be 2 repositories. One for examples and one for fpb. What's
>> the goal of keeping fpb in directory and examples on top? This breaks a
>> couple of things
>>
>> b. I cannot build fpm with simple
>>
>> pip install git+https://
>>
>> Instead I am forced to do
>>
>> git clone https://
>>
>> cd fuel-plugins
>>
>> pip install .
>>
>>
>>
>> c. There is no tags as I can see only stable/6.0
>>
>> d. There are no tests to improve code quality pep8 flask8, code coverage
>>
>> e. Repository doesn'

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Evgeniy L]

Hi Sheena,

Created ticket to change the structure of the directories [1].
And as far as I know any core can push tags into the repository,
Sebastian, Igor and I.

[1] https://bugs.launchpad.net/fuel/+bug/1479785

On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson 
wrote:

> Evgeniy –
>
>
>
> For the items which you have listed actions, who should be responsible for
> next steps?
>
>
>
> Sheena
>
>
>
> *From:* Evgeniy L [mailto:e...@mirantis.com]
> *Sent:* Tuesday, July 28, 2015 11:54 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Fuel][Plugins] Feedback
>
>
>
> Hi Sergii, thank you for feedback,
>
>
>
> >> c. There is no documentation how to install fpb from github master
> branch. It's very useful for developers who want to use latest version. We
> should add something
>
>
>
> We had a documentation, but removed it because the newer fpb was released,
>
> probably we should add this information permanently [1].
>
>
>
> >> a. We are doing the same mistake putting all things into one basket.
> There should be 2 repositories. One for examples and one for fpb. What's
> the goal of keeping fpb in directory and examples on top?
>
>
>
> These plugins are the data which are required for integration testing,
>
> we test that plugin build is not broken, which we run when patch gets
>
> published. I see nothing wrong with having the data for integration testing
>
> in the same repository with product which should be tested.
>
> Also in previous release we *removed* all the plugins which are not
>
> related to the builder itself, lbaas and glusterfs.
>
>
>
> >> This breaks a couple of things
>
>
>
> Having data for testing in the repository doesn't break anything.
>
>
>
> >> b. I cannot build fpm with simple
>
>
>
> That is a good point, we should move code from fuel_plugin_builder
> directory
>
> on top level, and move data for testing into examples directory.
>
>
>
> >> c. There is no tags as I can see only stable/6.0
>
>
>
> Correct, tags should be added.
>
>
>
> >> d. There are no tests to improve code quality pep8 flask8, code coverage
>
>
>
> That is not true, there are more then one hundreds unit tests which we run
>
> for each patch with python 2.6 and python 2.7, also there are integration
> tests
>
> which check that for each patch we don't break validation and that we can
>
> build plugins for previous versions. Plus there are functional tests which
> are
>
> written by fuel-qa team, those tests check that we perform deployment
>
> with plugins and required functionality works correctly. Also there *is*
> pep8
>
> check [2].
>
>
>
> >> e. Repository doesn't follow community standards.
>
>
>
> I think this issue should be resolved with moving fuel_plugin_builder
> directory
>
> on level higher, if not, please provide more specific description what is
> wrong.
>
>
>
> >> 3. Setting tab ...
>
>
>
> Agree.
>
>
>
> [1]
> https://wiki.openstack.org/w/index.php?title=Fuel%2FPlugins&diff=78677&oldid=78204
>
> [2]
> https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/tox.ini#L17-L21
>
>
>
> On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk <
> sgolovat...@mirantis.com> wrote:
>
> Hi,
>
> I have started digging into plugins recently. There are many positive
> things though I would like to point to some problem areas
>
> 1. Documentation
>
> a. It doesn't include the features of 7.0. There are many outstanding
> features, though I needed to ping the developers to ask how these features
> work. It means that it's almost impossible to develop plugins for upcoming
> releases. The external developer needs to wait for documentation so it
> creates a lag between release and plugin release.
>
> b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended
> to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent
> to 12.04
>
> c. There is no documentation how to install fpb from github master branch.
> It's very useful for developers who want to use latest version. We should
> add something
>
> 2. Github repository [2] is messed up
>
> a. We are doing the same mistake putting all things into one basket. There
> should be 2 repositories. One for examples and one for fpb. What's the goal
> of keeping fpb in directory and examples on top? This breaks a couple of
> things
>
> b. I cannot build fpm with simple
>
> pip install git+https://
>
> Instead I am forced to do
>
> git clone https://
>
> cd fuel-plugins
>
> pip install .
>
>
>
> c. There is no tags as I can see only stable/6.0
>
> d. There are no tests to improve code quality pep8 flask8, code coverage
>
> e. Repository doesn't follow community standards.
>
>
>
> 3. Setting tab
>
> When plugin is installed, it's very hard to find in. In setting tab it's
> somewhere between A and Z
>
> How is user supposed to find it? There should be a separator between Core
> features and plugins. User must easily find, configure, enable/dis

Re: [openstack-dev] [puppet] weekly meeting #44

[Emilien Macchi]

On 07/30/2015 07:01 AM, Sebastien Badia wrote:
> On Mon, Jul 27, 2015 at 10:01:26AM (-0400), Emilien Macchi wrote:
>> Hello team,
>>
>> Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC
>> in #openstack-meeting-4:
>>
>> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150728
>>
>> Please add additional items you'd like to discuss.
>> If our schedule allows it, we'll make bug triage during the meeting.
>>
>> See you there!
>> -- 
>> Emilien Macchi
> 
> We did our meeting! You can read notes here:
> http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-07-28-15.00.html
> 
> We can maybe use now the meeting id « puppet » for our meetings ?

Becaue mfish misspelled it 10 days ago, not a big deal :-)

> We have some inconsistency in the logs :-)

It's only one time, but since the beginning, meetings are
puppet-openstack and will stay like this. The project is by the way
named PuppetOpenStack (see governance).

>   « #startmeeting puppet » would be great.
> 
>   http://eavesdrop.openstack.org/meetings/puppet_openstack/
>   http://eavesdrop.openstack.org/meetings/puppet/
> 
> Ps, all our meetings + notes are logged also here
> 
>   https://wiki.openstack.org/wiki/Meetings/PuppetOpenStack
> 
> I just fixed the meeting_id for the « past meeting » link of eavesdrop
> 
>   http://eavesdrop.openstack.org/#Puppet_OpenStack_Team_Meeting
>   https://review.openstack.org/207389
> 
> Have a great day!
> 
> Seb
> 
> 
> 
> __
> 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
> 

-- 
Emilien Macchi



signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] Make libguestfs available on pypi

[Richard W.M. Jones]

On Thu, Jul 30, 2015 at 11:14:20AM +1000, Ian Wienand wrote:
> On 07/30/2015 04:55 AM, Kris G. Lindgren wrote:
> > The following bug has already been created over a year ago [1], and
> > it looks like most of the work on the libguestfs side is already
> > done [2].  It seems something about a complaint of licensing per
> > the bug report.
> 
> I think best to follow up in that bug
> 
> On the license front, to quote from an internal email I
> saw fly-by about the pypi sign-up terms under question from Nick on
> 20-Jul-2015:
> 
> ---
>  Van started drafting some amendments back in February:
>  https://bitbucket.org/vanl/pypi/commits/all
> 
>  Key changes are here:
>  
> https://bitbucket.org/vanl/pypi/commits/8df8e0295c0a719e963f7c3ce430284179f03b1f
> 
>  Further clarifications at
>  
> https://bitbucket.org/vanl/pypi/commits/734b1f49776d1f7f5d0671306f61a90aad713e5d
>  and
>  
> https://bitbucket.org/vanl/pypi/commits/0e94b169e81306607936912ecc3c42312aac5eb7
> 
>  I'll ping the Board list about next steps in getting those amendments
>  formally approved and submitted as a PR to the main PyPI repo.
> ---
> 
> So it is being looked at, but I'm not sure of the time-frame.

Yup, you beat me to it.  Earlier this month I asked the Python
Software Foundation to look again at their terms, and they have agreed
to make some changes.  It's my understanding that it is waiting on the
PSF Board to approve changes.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

__
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

Re: [openstack-dev] [designate] The designate API service is stopped

[Kiall Mac Innes]

So, I see three things of interest in the logs here.

1) The SIGHUP signal received

> 2015-07-28 14:49:10.378 22487 INFO oslo_service.service [-] Caught
> SIGHUP, exiting

Do we know what's sending this to signal to Designate?

2) The first exception, "Calling waitall() ..."

> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup
> AssertionError: Calling waitall() from within one of the GreenPool's
> greenthreads will never terminate.

We believe this to be effectively harmless, though still an open bug:

https://bugs.launchpad.net/designate/+bug/1442141

3) The second exception, "Could not bind ..."

> 2015-07-28 14:49:40.445 22487 ERROR oslo_service.threadgroup [-] Could
> not bind to 0.0.0.0:9001  after trying for 30 seconds

What kernel version are you running?

Can you try:

a) Removing the socket.SO_REUSEADDR option from the API socket

Approx L211 of designate/service.py, comment this line out:

> sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

b) Putting socket.SO_REUSEADDR back in, and adding socket.SO_REUSEPORT.

This will need a 3.9+ kernel. Approx L211 of designate/service.py, add
this line:

> sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)


Thanks,
Kiall


On 29/07/15 09:35, Jaime Fernández wrote:
> Hi Kiall,
> 
> We haven't found the cause yet. Even moving the host to the same
> network, the error still happens :(
> 
> We decided to migrate to rabbitmq. While migrating OST to rabbitmq, I've
> connected to the local rabbitmq, and I've also seen the same problem
> (all designate processes and rabbitmq in the same host). In this
> occasion, the designate-api process died after 5 hours.
> 
> Here it is the logs:
> 
> 2015-07-28 12:37:52.730 22487 INFO eventlet.wsgi
> [req-84e3674a-860e-46bf-b7a7-b9866866152d noauth-user
> 4e3b6c0108f04b309737522a9deee9d8 - - -] 127.0.0.1 - - [28/Jul/2015
> 12:37:52] "GET /v1/domains/38f8f79d-0f6c-42fb-abd7-98ae8cc87fc5/records
> HTTP/1.1" 200 1757 0.049479
> 2015-07-28 14:49:10.378 22487 INFO oslo_service.service [-] Caught
> SIGHUP, exiting
> 2015-07-28 14:49:10.379 22487 INFO designate.service [-] Stopping api
> service
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup [-] Error
> stopping thread.
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup Traceback
> (most recent call last):
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup   File
> "/home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/oslo.service-0.4.0-py2.7.egg/oslo_service/threadgroup.py",
> line 107, in _stop_threads
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup x.stop()
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup   File
> "/home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/oslo.service-0.4.0-py2.7.egg/oslo_service/threadgroup.py",
> line 48, in stop
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup
> self.thread.kill()
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup   File
> "/home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/eventlet-0.17.4-py2.7.egg/eventlet/greenthread.py",
> line 240, in kill
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup return
> kill(self, *throw_args)
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup   File
> "/home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/eventlet-0.17.4-py2.7.egg/eventlet/greenthread.py",
> line 294, in kill
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup
> g.throw(*throw_args)
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup   File
> "/home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/eventlet-0.17.4-py2.7.egg/eventlet/greenthread.py",
> line 214, in main
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup result
> = function(*args, **kwargs)
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup   File
> "/home/sysadmin/openstack/designate/designate/service.py", line 230, in
> _wsgi_handle
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup
> log=loggers.WritableLogger(logger))
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup   File
> "/home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/eventlet-0.17.4-py2.7.egg/eventlet/wsgi.py",
> line 842, in server
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup
> pool.waitall()
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup   File
> "/home/sysadmin/openstack/designate/.venv/local/lib/python2.7/site-packages/eventlet-0.17.4-py2.7.egg/eventlet/greenpool.py",
> line 117, in waitall
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup
> "Calling waitall() from within one of the " \
> 2015-07-28 14:49:10.379 22487 ERROR oslo_service.threadgroup
> AssertionError: Calling waitall() from within one of the GreenPool's
> greenthreads will never terminate.

Re: [openstack-dev] [neutron]How to use external_net?

[ZZelle]

Hi,

You need a router to bind internal network(s) with external network.

Otherwise you cannot allocate a floating ip (on the external network) to
VMs (on internal network(s)).

The doc[1] explains how to do it.

[1]
http://docs.openstack.org/kilo/install-guide/install/apt/content/neutron_initial-tenant-network.html


Cédric/ZZelle


On Thu, Jul 30, 2015 at 1:08 PM, 于洁 <16189...@qq.com> wrote:

> Hi all,
>   I find that if setting the value of router:external=True for a
> net(example: neutron net-update netID --router:external=True)
>   Users in other tenants could allocate floating IP from this
> net(example: neutron floatingip-create netID).
>   But how could this floating IP bind to a VM created by the user from
> other tenants? The network is unreachable.
>   Or do I misunderstand the function?
>
> Thanks,
> Yu
>
> __
> 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 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-dev] [kilo-multinode] Live-Migration Error

[Abhishek Talwar]

Hi,I have a multinode OpenStack kilo setup with 2 compute nodes, a 
controller and a network node. I am trying to migrate a Vm from host to 
the other, but there is a migration failure and the VM stays on the same
 host. I can ping between the compute nodes, and I have set libvirt to listen mode. Using the following steps: Modify /etc/libvirt/libvirtd.conf. 
before : #listen_tls = 0
after : listen_tls = 0 before : #listen_tcp = 1
after : listen_tcp = 1 add: auth_tcp = "none" Modify /etc/init/libvirt-bin.conf. 
before : exec /usr/sbin/libvirtd -d
after : exec /usr/sbin/libvirtd -d -l
-l is short for –listenModify /etc/default/libvirt-bin. 
before :libvirtd_opts=" -d"
after :libvirtd_opts=" -d -l"Restart libvirt. After executing the command, ensure that libvirt is successfully restarted. 
$ stop libvirt-bin && start libvirt-bin
$ ps -ef | grep libvirt Nova compute(Compute) logs: 2015-07-30
 10:05:56.928 2101 ERROR nova.virt.libvirt.driver [-] [instance: 
e8a310e6-3682-44fd-93b2-4e2564de047d] Live Migration failure: operation 
failed: Failed to connect to remote libvirt URI 
qemu+tcp://compute1-VirtualBox/system: Unable to resolve address 
'compute1-VirtualBox' service '16509': Name or service not known
2015-07-30 10:05:57.029 2101 ERROR nova.virt.libvirt.driver [-] 
[instance: e8a310e6-3682-44fd-93b2-4e2564de047d] Migration operation has
 aborted
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you



__
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-dev] [neutron]How to use external_net?

[????]

Hi all,
  I find that if setting the value of router:external=True for a 
net(example: neutron net-update netID --router:external=True)
  Users in other tenants could allocate floating IP from this net(example: 
neutron floatingip-create netID).
  But how could this floating IP bind to a VM created by the user from 
other tenants? The network is unreachable.
  Or do I misunderstand the function?


Thanks,
Yu__
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

Re: [openstack-dev] [puppet] weekly meeting #44

[Sebastien Badia]

On Mon, Jul 27, 2015 at 10:01:26AM (-0400), Emilien Macchi wrote:
> Hello team,
> 
> Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC
> in #openstack-meeting-4:
> 
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150728
> 
> Please add additional items you'd like to discuss.
> If our schedule allows it, we'll make bug triage during the meeting.
> 
> See you there!
> -- 
> Emilien Macchi

We did our meeting! You can read notes here:
http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-07-28-15.00.html

We can maybe use now the meeting id « puppet » for our meetings ?
We have some inconsistency in the logs :-)

  « #startmeeting puppet » would be great.

  http://eavesdrop.openstack.org/meetings/puppet_openstack/
  http://eavesdrop.openstack.org/meetings/puppet/

Ps, all our meetings + notes are logged also here

  https://wiki.openstack.org/wiki/Meetings/PuppetOpenStack

I just fixed the meeting_id for the « past meeting » link of eavesdrop

  http://eavesdrop.openstack.org/#Puppet_OpenStack_Team_Meeting
  https://review.openstack.org/207389

Have a great day!

Seb

-- 
Sebastien Badia


signature.asc
Description: Digital signature
__
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

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

[Alan Pevec]

>> Agreed, after 2015.1.2 version bumps are merged, I'll propose version=
>> line removals on stable branches so this situation doesn't happen
>> again.
>
> Err, no.
>
> Post-versioning means all projects use semantic rather than date-based
> version numbers, which happens starting with *liberty*. Remaining kilo
> and juno stable releases will still need to use pre-versioning.

Actually, post/pre doesn't make a difference on stable branches.
I tried locally on keystone stable/kilo and generated versions stay the same.

* current pre-version setup i.e. version = 2015.1.2 in setup.cfg
** commit 070b51603879f0f70f85f72e9e82126d1bb398ba Bump stable/kilo
next version to 2015.1.2
2015.1.2.dev1
** review 205130 rebased on top of 070b516 Bump...
2015.1.2.dev2

* post-version i.e. version = line removed from setup.cfg on top of
070b516 Bump...
commit fb9582acc739d7719da0f1cc5f29b9e24097e025
Author: Alan Pevec 
Date:   Thu Jul 30 12:07:27 2015 +0200

Switch to post-versioning

Change-Id: Ie4758058672bdeff86147f796d53f602a65228f1

diff --git a/setup.cfg b/setup.cfg
index e8d84e3..da0edb9 100644
--- a/setup.cfg
+++ b/setup.cfg
@@ -1,6 +1,5 @@
 [metadata]
 name = keystone
-version = 2015.1.2
 summary = OpenStack Identity
 description-file =
 README.rst

2015.1.2.dev2

** review 205130 rebased on top of Switch to post-versioning
2015.1.2.dev3

And when I tag that commit locally:
$ git tag 2015.1.2
$ python ./setup.py --version
2015.1.2

Then one backport on top of that:
2015.1.3.dev1

So all is good and safe to remove version = lines from setup.cfg on
stable branches.

Cheers,
Alan

__
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

Re: [openstack-dev] [puppet] Parameters possible default value

[Sebastien Badia]

On Mon, Jul 27, 2015 at 09:43:28PM (+), Andrew Woodward wrote:
> Sorry, I forgot to finish this up and send it out.
> 
> #--SNIP--
> def absent_default(
>   $value,
>   $default,
>   $unset_when_default = true,
> ){
>   if ( $value == $default ) and $unset_when_default {
> # I cant think of a way to deal with this in a define so lets pretend
> # we can re-use this with multiple providers like we could if this was
> # in the actual provider.
> 
> keystone_config {$name: ensure => absent,}
>   } else {
> keystone_config {$name: value = $value,}
>   }
> }
> 
> # Usage:
> absent_default{'DEFAULT/foo': default => 'bar', value => $foo }

Hi,

Hum, but you want to add this definition in all our modules, or directly in
openstacklib?

In case of openstacklib, in which manner do you define the _config
resource? (eg, generic def, but specialized resource).

> #--SNIP--
> 
> (I threw this together and haven't tried to run it yet, so It might not run
> verbatim, I will create a test project with it to show it working)
> 
> So In the long-term we should be able to add some new functionality to the
> inifile provider to simply just do this for us. We can add the 'default'
> and 'unset_when_default' parameter so that we can use them straight w/o a
> wrapping function (but the warping function could be used too). This would
> give us the defaults (I have an idea on that too that I will try to put
> into the prototype) that should allow us to have something that looks quite
> clean, but is highly functional
> 
> > Keystone_config{unset_when_default => true} #probably flatly enabled in
> our inifile provider for the module
> > keystone_config {'DEFAULT/foo': value => 'bar', default => 'bar'}


I'm not sure to see the difference with the Yanis solution here¹, and not sure
to see the link between the define resource and the type/provider resource.

Seb

¹https://review.openstack.org/#/c/202574/
-- 
Sebastien Badia


signature.asc
Description: Digital signature
__
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

Re: [openstack-dev] [nova, cinder, neutron] quota-update tenant-name bug

[Fox, Kevin M]

Can a non admin update quotas? Quota updates are rare. Performance of them can 
take the hit.

Thanks,
Kevin


From: Kevin Benton
Sent: Wednesday, July 29, 2015 10:44:49 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova, cinder, neutron] quota-update tenant-name 
bug

>Dev lessons learned: we need to validate better our inputs and refuse to 
>update a tenant-id that does not exist.

This is something that has come up in Neutron discussions before. There are two 
issues here:
1. Performance: it will require a round-trip to Keystone on every request.
2. If the Neutron keystone user in unprivileged and the request context is 
unprivileged, we might not actually be allowed to tell if the tenant exists.

The first we can deal with, but the second is going to be an issue that we 
might not be able to get around.

How about as a temporary solution, we just confirm that the input is a UUID so 
names don't get used?

On Wed, Jul 29, 2015 at 10:19 PM, Bruno L 
mailto:teolupus@gmail.com>> wrote:
This is probably affecting other people as well, so hopefully message will 
avoid some headaches.

[nova,cinder,neutron] will allow you to do a quota-update using the tenant-name 
(instead of tenant-id). They will also allow you to do a quota-show tenant-name 
and get the expected values back.

Then you go to the tenant and end up surprised that the quotas have not been 
applied and you can still do things you were not supposed to.

It turns out that [nova,cinder,neutron] just created an entry on the quota 
table, inserting the tenant-name on the tenant-id field.

"Surprise, surprise!"

Ops lessons learned: use the tenant-id!

Dev lessons learned: we need to validate better our inputs and refuse to update 
a tenant-id that does not exist.

I have documented this behaviour on 
https://bugs.launchpad.net/neutron/+bug/1399065 and 
https://bugs.launchpad.net/neutron/+bug/1317515. I can reproduce it in IceHouse.

Could someone please confirm if this is still the case on master? If not, which 
version of OpenStack addressed that?

Thanks,
Bruno

__
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




--
Kevin Benton
__
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

Re: [openstack-dev] How to use the log server in CI ?

[Abhishek Shrivastava]

You should setup the LogServer in another machine apart from master/slave
because the logs machine should be a separate one not any other
master/slave.

On Thu, Jul 30, 2015 at 3:49 PM, Tang Chen  wrote:

>
> On 07/30/2015 05:48 PM, Abhishek Shrivastava wrote:
>
>  I am talking about "/srv/static/logs" folder.
>
>
> Yes, I see.
>
> But, I run the install_log_server.sh on my Jenkins Master, and configured
> $DOMAIN to another machine's hostname.
>
> Did I do this correctly ?
>
> After that, I can find "/srv/static/logs" on my Jenkins Master, and when I
> run a build, nothing new was created under that directory.
> And on the other machine, there is nothing.
>
> I'm wondering if I should run the script on the other machine ?
>
> I'm a little confused.
>
> Thanks.
>
>
> On Thu, Jul 30, 2015 at 3:18 PM, Abhishek Shrivastava <
> abhis...@cloudbyte.com> wrote:
>
>>  Hi Tang,
>>
>>  You can give any name in $DOMAIN, also try to run a build then see if
>> the logs are going to the LogServer, but before that clear that folder so
>> that you can see the difference.
>>
>> On Thu, Jul 30, 2015 at 3:15 PM, Tang Chen 
>> wrote:
>>
>>>
>>> On 07/30/2015 04:54 PM, Abhishek Shrivastava wrote:
>>>
>>>  Hi Tang,
>>>
>>>  After completing the logServer installation the logs will go to your
>>> machine automatically after each build run.
>>>
>>>
>>>  But I cannot find anything new under /srv/static/logs/.
>>> Shouldn't the new logs be under this directory ?
>>>
>>>
>>>
>>> On Thu, Jul 30, 2015 at 2:19 PM, Tang Chen 
>>> wrote:
>>>
  Hi Asselin, Abhishek,

 Sorry, it is about the CI again.

 I run install_log_server.sh to setup a log server.

 I setup the log server on the same machine with my Jenkins Master, and
 configured it like this:
 $DOMAIN=localhost
 $JENKINS_SSH_PUBLIC_KEY = path to my ssh key

 The script completed. But I don't know how to use the log server.

 Here are my questions:

 1. Is the log server able to be on the same machine with Jenkins Master
 ?
 I think maybe the apache in the log server conflicts with the
 jenkins server.

>>>
>>>  ​ The answer to your question is no, as the logs generated​
>>>
>>> ​ each time will become large in size so it is recommended to use
>>> logServer on a separate machine having a public IP.
>>>
>>>
>>>  What if I just want to setup it in a local environment and try to use
>>> it ?
>>>
>>> What should I configure the $DOMAIN ?  I don't have a public hostname
>>> now.
>>>
>>> Thanks.
>>>
>>>
 2. Is the log server able to upload the logs to Gerrit automatically ?
 Or it is just a server for you to view the logs ?

>>>
>>>  ​ The logs is not uploaded to Gerrit, only success or failure is
>>> reported to Gerrit. Also, when you click on the job in the gerrit with
>>> either of the message, you will be redirected to the logServer page.​
>>>
>>>

 I raised an issue on github.  You can also discuss this on github if
 you like.
 (https://github.com/rasselin/os-ext-testing/issues/19)

 I also asked about this in IRC #openstack-infra, but it seems that very
 few people are using os-ext-testing.

 Thanks.

>>>
>>>
>>>
>>>  --
>>>
>>>
>>> *Thanks & Regards, *
>>> *Abhishek*
>>>  *Cloudbyte Inc. *
>>>
>>>
>>>
>>
>>
>>  --
>>
>>
>> *Thanks & Regards, *
>> *Abhishek*
>>  *Cloudbyte Inc. *
>>
>
>
>
>  --
>
>
> *Thanks & Regards, *
> *Abhishek*
>  *Cloudbyte Inc. *
>
>
>


-- 


*Thanks & Regards,*
*Abhishek*
*Cloudbyte Inc. *
__
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

Re: [openstack-dev] How to use the log server in CI ?

[Tang Chen]

On 07/30/2015 05:48 PM, Abhishek Shrivastava wrote:

I am talking about "/srv/static/logs" folder.


Yes, I see.

But, I run the install_log_server.sh on my Jenkins Master, and 
configured $DOMAIN to another machine's hostname.


Did I do this correctly ?

After that, I can find "/srv/static/logs" on my Jenkins Master, and when 
I run a build, nothing new was created under that directory.

And on the other machine, there is nothing.

I'm wondering if I should run the script on the other machine ?

I'm a little confused.

Thanks.



On Thu, Jul 30, 2015 at 3:18 PM, Abhishek Shrivastava 
mailto:abhis...@cloudbyte.com>> wrote:


Hi Tang,

You can give any name in $DOMAIN, also try to run a build then see
if the logs are going to the LogServer, but before that clear that
folder so that you can see the difference.

On Thu, Jul 30, 2015 at 3:15 PM, Tang Chen
mailto:tangc...@cn.fujitsu.com>> wrote:


On 07/30/2015 04:54 PM, Abhishek Shrivastava wrote:

Hi Tang,

After completing the logServer installation the logs will go
to your machine automatically after each build run.



But I cannot find anything new under /srv/static/logs/.
Shouldn't the new logs be under this directory ?




On Thu, Jul 30, 2015 at 2:19 PM, Tang Chen
mailto:tangc...@cn.fujitsu.com>> wrote:

Hi Asselin, Abhishek,

Sorry, it is about the CI again.

I run install_log_server.sh to setup a log server.

I setup the log server on the same machine with my
Jenkins Master, and configured it like this:
$DOMAIN=localhost
$|JENKINS_SSH_PUBLIC_KEY| = path to my ssh key

The script completed. But I don't know how to use the log
server.

Here are my questions:

1. Is the log server able to be on the same machine with
Jenkins Master ?
I think maybe the apache in the log server conflicts
with the jenkins server.


​ The answer to your question is no, as the logs generated​
​ each time will become large in size so it is recommended to
use logServer on a separate machine having a public IP.


What if I just want to setup it in a local environment and try
to use it ?

What should I configure the $DOMAIN ?  I don't have a public
hostname now.

Thanks.



2. Is the log server able to upload the logs to Gerrit
automatically ?
Or it is just a server for you to view the logs ?


​ The logs is not uploaded to Gerrit, only success or failure
is reported to Gerrit. Also, when you click on the job in the
gerrit with either of the message, you will be redirected to
the logServer page.​


I raised an issue on github.  You can also discuss this
on github if you like.
(https://github.com/rasselin/os-ext-testing/issues/19)

I also asked about this in IRC #openstack-infra, but it
seems that very few people are using os-ext-testing.

Thanks.




-- 
*

*
*Thanks & Regards,
*
*Abhishek*
/_Cloudbyte Inc. _/





-- 
*

*
*Thanks & Regards,
*
*Abhishek*
/_Cloudbyte Inc. _/




--
*
*
*Thanks & Regards,
*
*Abhishek*
/_Cloudbyte Inc. _/


__
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

Re: [openstack-dev] How to use the log server in CI ?

[Abhishek Shrivastava]

I am talking about "/srv/static/logs" folder.

On Thu, Jul 30, 2015 at 3:18 PM, Abhishek Shrivastava <
abhis...@cloudbyte.com> wrote:

> Hi Tang,
>
> You can give any name in $DOMAIN, also try to run a build then see if the
> logs are going to the LogServer, but before that clear that folder so that
> you can see the difference.
>
> On Thu, Jul 30, 2015 at 3:15 PM, Tang Chen 
> wrote:
>
>>
>> On 07/30/2015 04:54 PM, Abhishek Shrivastava wrote:
>>
>>  Hi Tang,
>>
>>  After completing the logServer installation the logs will go to your
>> machine automatically after each build run.
>>
>>
>> But I cannot find anything new under /srv/static/logs/.
>> Shouldn't the new logs be under this directory ?
>>
>>
>>
>> On Thu, Jul 30, 2015 at 2:19 PM, Tang Chen 
>> wrote:
>>
>>>  Hi Asselin, Abhishek,
>>>
>>> Sorry, it is about the CI again.
>>>
>>> I run install_log_server.sh to setup a log server.
>>>
>>> I setup the log server on the same machine with my Jenkins Master, and
>>> configured it like this:
>>> $DOMAIN=localhost
>>> $JENKINS_SSH_PUBLIC_KEY = path to my ssh key
>>>
>>> The script completed. But I don't know how to use the log server.
>>>
>>> Here are my questions:
>>>
>>> 1. Is the log server able to be on the same machine with Jenkins Master ?
>>> I think maybe the apache in the log server conflicts with the
>>> jenkins server.
>>>
>>
>>  ​ The answer to your question is no, as the logs generated​
>>
>> ​ each time will become large in size so it is recommended to use
>> logServer on a separate machine having a public IP.
>>
>>
>> What if I just want to setup it in a local environment and try to use it ?
>>
>> What should I configure the $DOMAIN ?  I don't have a public hostname now.
>>
>> Thanks.
>>
>>
>>> 2. Is the log server able to upload the logs to Gerrit automatically ?
>>> Or it is just a server for you to view the logs ?
>>>
>>
>>  ​ The logs is not uploaded to Gerrit, only success or failure is
>> reported to Gerrit. Also, when you click on the job in the gerrit with
>> either of the message, you will be redirected to the logServer page.​
>>
>>
>>>
>>> I raised an issue on github.  You can also discuss this on github if you
>>> like.
>>> (https://github.com/rasselin/os-ext-testing/issues/19)
>>>
>>> I also asked about this in IRC #openstack-infra, but it seems that very
>>> few people are using os-ext-testing.
>>>
>>> Thanks.
>>>
>>
>>
>>
>>  --
>>
>>
>> *Thanks & Regards, *
>> *Abhishek*
>>  *Cloudbyte Inc. *
>>
>>
>>
>
>
> --
>
>
> *Thanks & Regards,*
> *Abhishek*
> *Cloudbyte Inc. *
>



-- 


*Thanks & Regards,*
*Abhishek*
*Cloudbyte Inc. *
__
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

Re: [openstack-dev] How to use the log server in CI ?

[Abhishek Shrivastava]

Hi Tang,

You can give any name in $DOMAIN, also try to run a build then see if the
logs are going to the LogServer, but before that clear that folder so that
you can see the difference.

On Thu, Jul 30, 2015 at 3:15 PM, Tang Chen  wrote:

>
> On 07/30/2015 04:54 PM, Abhishek Shrivastava wrote:
>
>  Hi Tang,
>
>  After completing the logServer installation the logs will go to your
> machine automatically after each build run.
>
>
> But I cannot find anything new under /srv/static/logs/.
> Shouldn't the new logs be under this directory ?
>
>
>
> On Thu, Jul 30, 2015 at 2:19 PM, Tang Chen 
> wrote:
>
>>  Hi Asselin, Abhishek,
>>
>> Sorry, it is about the CI again.
>>
>> I run install_log_server.sh to setup a log server.
>>
>> I setup the log server on the same machine with my Jenkins Master, and
>> configured it like this:
>> $DOMAIN=localhost
>> $JENKINS_SSH_PUBLIC_KEY = path to my ssh key
>>
>> The script completed. But I don't know how to use the log server.
>>
>> Here are my questions:
>>
>> 1. Is the log server able to be on the same machine with Jenkins Master ?
>> I think maybe the apache in the log server conflicts with the jenkins
>> server.
>>
>
>  ​ The answer to your question is no, as the logs generated​
>
> ​ each time will become large in size so it is recommended to use
> logServer on a separate machine having a public IP.
>
>
> What if I just want to setup it in a local environment and try to use it ?
>
> What should I configure the $DOMAIN ?  I don't have a public hostname now.
>
> Thanks.
>
>
>> 2. Is the log server able to upload the logs to Gerrit automatically ?
>> Or it is just a server for you to view the logs ?
>>
>
>  ​ The logs is not uploaded to Gerrit, only success or failure is
> reported to Gerrit. Also, when you click on the job in the gerrit with
> either of the message, you will be redirected to the logServer page.​
>
>
>>
>> I raised an issue on github.  You can also discuss this on github if you
>> like.
>> (https://github.com/rasselin/os-ext-testing/issues/19)
>>
>> I also asked about this in IRC #openstack-infra, but it seems that very
>> few people are using os-ext-testing.
>>
>> Thanks.
>>
>
>
>
>  --
>
>
> *Thanks & Regards, *
> *Abhishek*
>  *Cloudbyte Inc. *
>
>
>


-- 


*Thanks & Regards,*
*Abhishek*
*Cloudbyte Inc. *
__
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

Re: [openstack-dev] How to use the log server in CI ?

[Tang Chen]

On 07/30/2015 04:54 PM, Abhishek Shrivastava wrote:

Hi Tang,

After completing the logServer installation the logs will go to your 
machine automatically after each build run.




But I cannot find anything new under /srv/static/logs/.
Shouldn't the new logs be under this directory ?




On Thu, Jul 30, 2015 at 2:19 PM, Tang Chen > wrote:


Hi Asselin, Abhishek,

Sorry, it is about the CI again.

I run install_log_server.sh to setup a log server.

I setup the log server on the same machine with my Jenkins Master,
and configured it like this:
$DOMAIN=localhost
$|JENKINS_SSH_PUBLIC_KEY| = path to my ssh key

The script completed. But I don't know how to use the log server.

Here are my questions:

1. Is the log server able to be on the same machine with Jenkins
Master ?
I think maybe the apache in the log server conflicts with the
jenkins server.


​ The answer to your question is no, as the logs generated​
​ each time will become large in size so it is recommended to use 
logServer on a separate machine having a public IP.


What if I just want to setup it in a local environment and try to use it ?

What should I configure the $DOMAIN ?  I don't have a public hostname now.

Thanks.



2. Is the log server able to upload the logs to Gerrit automatically ?
Or it is just a server for you to view the logs ?


​ The logs is not uploaded to Gerrit, only success or failure is 
reported to Gerrit. Also, when you click on the job in the gerrit with 
either of the message, you will be redirected to the logServer page.​



I raised an issue on github.  You can also discuss this on github
if you like.
(https://github.com/rasselin/os-ext-testing/issues/19)

I also asked about this in IRC #openstack-infra, but it seems that
very few people are using os-ext-testing.

Thanks.




--
*
*
*Thanks & Regards,
*
*Abhishek*
/_Cloudbyte Inc. _/


__
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

Re: [openstack-dev] [magnum][blueprint] magnum-service-list

[Jay Lau]

Hi Suro,

In my understanding, even other CoE might have service/pod/rc concepts in
future, we may still want to distinguish the "magnum service-list" with
"magnum coe-service-list".

service-list is mainly for magnum native services, such as magnum-api,
magnum-conductor etc.
coe-service-list mainly for the services that running for the CoEs in
magnum.

Thoughts? Thanks.

2015-07-29 17:50 GMT-04:00 SURO :

>  Hi Hongbin,
>
> What would be the value of having COE-specific magnum command to go and
> talk to DB? As in that case, user may use the native client itself to fetch
> the data from COE, which even will have latest state.
>
> In a pluggable architecture there is always scope for common abstraction
> and driver implementation. I think it is too early to declare
> service/rc/pod as specific to k8s, as the other COEs may very well converge
> onto similar/same concepts.
>
> Regards,
> SURO
> irc//freenode: suro-patz
>
> On 7/29/15 2:21 PM, Hongbin Lu wrote:
>
>  Suro,
>
>
>
> I think service/pod/rc are k8s-specific. +1 for Jay’s suggestion about
> renaming COE-specific command, since the new naming style looks consistent
> with other OpenStack projects. In addition, it will eliminate name
> collision of different COEs. Also, if we are going to support pluggable
> COE, adding prefix to COE-specific command is unavoidable.
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> *From:* SURO [mailto:suro.p...@gmail.com ]
> *Sent:* July-29-15 4:03 PM
> *To:* Jay Lau
> *Cc:* s...@yahoo-inc.com; OpenStack Development Mailing List (not for
> usage questions)
> *Subject:* Re: [openstack-dev] [magnum][blueprint] magnum-service-list
>
>
>
> Hi Jay,
>
> 'service'/'pod'/'rc' are conceptual abstraction at magnum level. Yes, the
> abstraction was inspired from the same in kubernetes, but the data stored
> in DB about a 'service' is properly abstracted and not k8s-specific at the
> top level.
>
> If we plan to change this to 'k8s-service-list', the same applies for even
> creation and other actions. This will give rise to COE-specific command and
> concepts and which may proliferate further. Instead, we can abstract
> swarm's service concept under the umbrella of magnum's 'service' concept
> without creating k8s-service and swarm-service.
>
> I suggest we should keep the concept/abstraction at Magnum level, as it
> is.
>
>  Regards,
>
> SURO
>
> irc//freenode: suro-patz
>
>  On 7/28/15 7:59 PM, Jay Lau wrote:
>
>   Hi Suro,
>
> Sorry for late. IMHO, even the "magnum service-list" is getting data from
> DB, but the DB is actually persisting some data for Kubernetes service, so
> my thinking is it possible to change "magnum service-list" to "magnum
> k8s-service-list", same for pod and rc.
>
> I know this might bring some trouble for backward compatibility issue, not
> sure if it is good to do such modification at this time. Comments?
>
> Thanks
>
>
>
> 2015-07-27 20:12 GMT-04:00 SURO < suro.p...@gmail.com
> >:
>
> Hi all,
> As we did not hear back further on the requirement of this blueprint, I
> propose to keep the existing behavior without any modification.
>
> We would like to explore the decision on this blueprint on our next weekly
> IRC meeting[1].
>
>
> Regards,
>
> SURO
>
> irc//freenode: suro-patz
>
>
>
> [1] - https://wiki.openstack.org/wiki/Meetings/Containers
>
>   2015-07-28
>
> UTC 2200 Tuesday
>
>
>
>  On 7/21/15 4:54 PM, SURO wrote:
>
> Hi all, [special attention: Jay Lau] The bp[1] registered, asks for the
> following implementation -
>
>- 'magnum service-list' should be similar to 'nova service-list'
>- 'magnum service-list' should be moved to be ' magnum
>k8s-service-list'. Also similar holds true for 'pod-list'/'rc-list'
>
> As I dug some details, I find -
>
>- 'magnum service-list' fetches data from OpenStack DB[2], instead of
>the COE endpoint. So technically it is not k8s-specific. magnum is serving
>data for objects modeled as 'service', just the way we are catering for
>'magnum container-list' in case of swarm bay.
>- If magnum provides a way to get the COE endpoint details, users can
>use native tools to fetch the status of the COE-specific objects, viz.
>'kubectl get services' here.
>- nova has lot more backend services, e.g. cert, scheduler,
>consoleauth, compute etc. in comparison to magnum's conductor only. Also,
>not all the api's have this 'service-list' available.
>
> With these arguments in view, can we have some more
> explanation/clarification in favor of the ask in the blueprint? [1] -
> https://blueprints.launchpad.net/magnum/+spec/magnum-service-list [2] -
> https://github.com/openstack/magnum/blob/master/magnum/objects/service.py#L114
>
> --
>
> Regards,
>
> SURO
>
> irc//freenode: suro-patz
>
>
>
>
> --
>
> Thanks,
>
> Jay Lau (Guangya Liu)
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.or

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

[Alan Pevec]

> The way we did it in the past was to push the setup.cfg version=2015.1.2
> bump BEFORE we tag, then once that is merged, tag the previous commit in
> history as 2015.1.1. That way you avoid the lockstep (and ensure no
> intermediary badly-versioned tarball can be produced).
>
> Any reason why that wouldn't work anymore ?

It should've worked but we didn't update the current stable release
procedure which I was following.
We have documented pushing tags in step
https://wiki.openstack.org/wiki/StableBranchRelease#Tag
and pushing version bumps only later, after Close bugs and Upload The Release:
https://wiki.openstack.org/wiki/StableBranchRelease#Rinse.2C_Repeat

Let's update this procedure since we still have few Kilo and Juno
point releases to be done.


Cheers,
Alan

__
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

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

[Thierry Carrez]

Alan Pevec wrote:
>> I think pushing them up earlier would indeed make it easier for folk.
> 
> Indeed, but it's too late now.
> 
>> But its not as good as using post-versioniing :)
> 
> Agreed, after 2015.1.2 version bumps are merged, I'll propose version=
> line removals on stable branches so this situation doesn't happen
> again.

Err, no.

Post-versioning means all projects use semantic rather than date-based
version numbers, which happens starting with *liberty*. Remaining kilo
and juno stable releases will still need to use pre-versioning.

The way we did it in the past was to push the setup.cfg version=2015.1.2
bump BEFORE we tag, then once that is merged, tag the previous commit in
history as 2015.1.1. That way you avoid the lockstep (and ensure no
intermediary badly-versioned tarball can be produced).

Any reason why that wouldn't work anymore ?

-- 
Thierry Carrez (ttx)

__
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-dev] [neutron][nova] some conflicts in bridge-mapping in linuxbridge

[Li Ma]

Hi all,

Currently, I'm implementing this blueprint:
https://blueprints.launchpad.net/neutron/+spec/phy-net-bridge-mapping

This function enables a user-defined pre-existed bridge to connect
instances , rather than creating a new bridge that may break security
rule of some companies.

Neutron code has been done recently, but I find that it is really
difficult to implement due to Nova.

Nova hard-code 'brq' + net-id as bridge name in libvirt configuration.

In nova/network/neutronv2/api.py:

def _nw_info_build_network(self, port, networks, subnets):

1530 elif vif_type == network_model.VIF_TYPE_BRIDGE:
1531 bridge = "brq" + port['network_id']

For example, in flat network type, when Neutron loads a pre-existed
user-defined bridge called 'br-eth1' and would like to let it connect
the instances, it will fail because Nova writes 'brq-net-id' into
libvirt conf file.

I have several solutions for that.

(1) Add the same 'bridge-mapping' configuration in nova.conf for
nova-compute. It is almost the same implementation in OVS-agent.
When nova needs bridge name to process, it first reads that
configuration and then decide which bridge to use.

(2) Let Neutron decide interface name (tap-xxx) and bridge name
(brq-xxx), not Nova. As a result, when creating port, Neutron return
interface name and bridge name to Nova, so Nova has the right device
name to process. This helps Nova get rid of hard-code, but need lots
of work on it.

Pls give some advice. Thanks a lot.

Li Ma (Nick)

__
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

Re: [openstack-dev] How to use the log server in CI ?

[Abhishek Shrivastava]

Hi Tang,

After completing the logServer installation the logs will go to your
machine automatically after each build run.



On Thu, Jul 30, 2015 at 2:19 PM, Tang Chen  wrote:

>  Hi Asselin, Abhishek,
>
> Sorry, it is about the CI again.
>
> I run install_log_server.sh to setup a log server.
>
> I setup the log server on the same machine with my Jenkins Master, and
> configured it like this:
> $DOMAIN=localhost
> $JENKINS_SSH_PUBLIC_KEY = path to my ssh key
>
> The script completed. But I don't know how to use the log server.
>
> Here are my questions:
>
> 1. Is the log server able to be on the same machine with Jenkins Master ?
> I think maybe the apache in the log server conflicts with the jenkins
> server.
>

​The answer to your question is no, as the logs generated​

​each time will become large in size so it is recommended to use logServer
on a separate machine having a public IP.

>
> 2. Is the log server able to upload the logs to Gerrit automatically ?
> Or it is just a server for you to view the logs ?
>

​The logs is not uploaded to Gerrit, only success or failure is reported to
Gerrit. Also, when you click on the job in the gerrit with either of the
message, you will be redirected to the logServer page.​


>
> I raised an issue on github.  You can also discuss this on github if you
> like.
> (https://github.com/rasselin/os-ext-testing/issues/19)
>
> I also asked about this in IRC #openstack-infra, but it seems that very
> few people are using os-ext-testing.
>
> Thanks.
>



-- 


*Thanks & Regards,*
*Abhishek*
*Cloudbyte Inc. *
__
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

Re: [openstack-dev] [Nova] Non-priority Feature Freeze is Tomorrow (July 30th)

[John Garbutt]

On 29 July 2015 at 19:20, John Garbutt  wrote:
> Hi,
>
> Tomorrow is: Non-priority Feature Freeze
>
> What does this mean? Well...
>
> * bug fixes: no impact, still free to merge
> * priority features: no impact, still free to merge
> * clean ups: sure we could merge those
> * non-priority features (i.e. blueprints with a low priority), you are
> no longer free to merge (we are free to re-approve previously approved
> things, due to gate issues / merge issues, if needed)
>
> Please note, the full Feature Freeze (and string freeze, etc), are
> when we tag liberty-3, which is expected to be on or just after
> September 1.
>
> This is all about focusing on merging more Bug Fixes and more Priority
> Features. For more details, please see:
> https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#Why_is_there_a_non-priority_Feature_Freeze_in_Nova.3F
>
> Its the same we did last release:
> http://lists.openstack.org/pipermail/openstack-dev/2015-February/056208.html
>
> Exceptions, I hear you cry? Lets follow a similar process as we did last 
> time...
>
> If you want an exception:
> * please add request in here:
>https://etherpad.openstack.org/p/liberty-nova-non-priority-feature-freeze
> * make sure you make your request before the end of Wednesday 6th August
> * nova-drivers will meet to decide what gets an exception (as before)
> * with the aim to merge the code for all exceptions by the end of
> Monday 10th August

I have added this detail into the wiki, as we refine the details:
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#Non-priority_Feature_Freeze

> There are unlikely to be many exceptions given, its really just for
> exceptional reasons why it didn't get merged in time.
>
> The folks in the nova-meeting tomorrow may need to refine this
> process, but if anything changes, we can send out an update to the ML.
>
> Thanks,
> johnthetubaguy
>
> PS
> Due to time constraints, its likely that it will be on Monday 3rd
> August, that I will -2 all non-priority blueprint patches, and
> un-approve all low priority blueprints, unless someone gets to that
> first.

Actually, I should be able to do this on Friday morning, as normal.
Bad timing, but I am mostly away from my computer over the next few
days, but I am watching email a bit. (Something that was booked before
the release dates were announced)

Note, I don't plan on blocking things that are just pending a merge.
I will only block things that don't have two +2 votes on them.
This should help us keep productive through the gate congestion/issues.

Thanks,
John

__
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

Re: [openstack-dev] [openstack-qa] [qa] tempest

[Frittoli, Andrea (HP Cloud)]

Hi,

please note that the openstack-qa distribution list is not used anywhere, we 
only keep it for periodic tests notifications.
You should use openstack-dev instead.

Documentation is available at [0] and in the sample file [1].
Tempest configuration is uploaded to logs after each CI job - see for instance 
[2].
You can use that to see how tempest is configured for different jobs and/or 
different branches.

You can also activate the tempest service in devstack, and you will get a 
functional tempest.conf in there based on your devstack setup.

hth

andrea

[0] http://docs.openstack.org/developer/tempest
[1] http://git.openstack.org/cgit/openstack/tempest/tree/etc/tempest.conf.sample
[2] 
http://logs.openstack.org/43/206643/2/check/gate-tempest-dsvm-full/37261f2/logs/tempest_conf.txt.gz


On 30 Jul 2015, at 08:58, wh王昊(IT) mailto:w_...@ctrip.com>> 
wrote:


Hi, There is my configuration file:

[DEFAULT]
lock_path=/var/lock/tempest
log_dir=/var/log/tempest

[cli]
enabled=true
cli_dir=/usr/bin
has_manage=false


[compute]
image_ref=b53bf015-ad14-4daf-ae54-496d2b69c1d3
image_ref_alt=b53bf015-ad14-4daf-ae54-496d2b69c1d3

flavor_ref=871a7187-e630-44e4-94a0-96b692e520df
flavor_ref_alt=3a176f86-3cb7-42d5-bc71-6e385172a903

build_timeout=600
run_ssh=false
ssh_auth_method=disabled
ssh_connect_method=floating
ip_version_for_ssh=4
use_floatingip_for_ssh=false
allow_tenant_isolation=True


[compute-admin]
username=admin
tenant_name=admin
password=**


[compute-feature-enabled]
api_v3=false
change_password=false
console_output=false
resize = true
pause = false
shelve=false
live_migration=false
snapshot = false


[dashboard]
dashboard_url=http://10.18.5.149/
login_url=http://10.18.5.149/auth/login/


[identity]
auth_version = v2
admin_domain_name = Default
admin_tenant_id = 8732aeea845543e9a5981e1a6d758512
admin_tenant_name = admin
admin_password = **
admin_username = admin
alt_tenant_name = alt_demo
alt_password = **
alt_username = alt_demo
tenant_name = demo
password = **
username = demo
uri_v3 = http://10.18.5.149:5000/v3/
uri = http://10.18.5.149:5000/v2.0/

[identity-feature-enabled]
trust=true
api_v2=true
api_v3=False


[network]
#default_network = 10.0.0.0/24
#public_router_id =
public_network_id = 663d43bc-461e-4c3e-bed8-384fa2ae8aff
tenant_networks_reachable = false
api_version = 2.0


[network-feature-enabled]
api_extensions = 
allowed-address-pairs,ext-gw-mode,binding,quotas,agent,dhcp_agent_scheduler,provider,external-net,extra_dhcp_opt,l3_agent_scheduler,router,extraroute
#api_extensions=all
ipv6_subnet_attributes = False
ipv6 = False

[service_available]
neutron = True
heat = False
ceilometer = False
swift = False
cinder = False
nova = True
glance = True
horizon = True

you can get image_ref id from horizon or use command line “nova image-list”.

发件人: Gil Halperin [mailto:gihalpe...@advaoptical.com]
发送时间: 2015年7月30日 15:41
收件人: openstack...@lists.openstack.org
主题: [openstack-qa] tempest

Hey, I would like to get help with Tempest, Ive been setting tempest up for 
testing my openstack server, I've been using testr to run the tests but I need 
some help to figure out stuff on the “tempest.config” file, for example, at the 
compute section, what "ID" do i need to write in the "image_ref" row?
is there any other manual or some help docs for tempest other than 
"http://docs.openstack.org/developer/tempest/configuration.html#tempest-configuration";
 ?
any other full explanation of “tempest.config” file?
thanks
___
openstack-qa mailing list
openstack...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa

__
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-dev] How to use the log server in CI ?

[Tang Chen]

Hi Asselin, Abhishek,**

Sorry, it is about the CI again.

I run install_log_server.sh to setup a log server.

I setup the log server on the same machine with my Jenkins Master, and 
configured it like this:

$DOMAIN=localhost
$|JENKINS_SSH_PUBLIC_KEY| = path to my ssh key

The script completed. But I don't know how to use the log server.

Here are my questions:

1. Is the log server able to be on the same machine with Jenkins Master ?
I think maybe the apache in the log server conflicts with the 
jenkins server.


2. Is the log server able to upload the logs to Gerrit automatically ?
Or it is just a server for you to view the logs ?

I raised an issue on github.  You can also discuss this on github if you 
like.

(https://github.com/rasselin/os-ext-testing/issues/19)

I also asked about this in IRC #openstack-infra, but it seems that very 
few people are using os-ext-testing.


Thanks.
__
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

Re: [openstack-dev] [Ironic] Lenovo driver submission requests

[Lucas Alvares Gomes]

On Thu, Jul 30, 2015 at 8:27 AM, Dmitry Tantsur  wrote:
> On 07/30/2015 08:59 AM, Kai KH Huang wrote:
>>
>> Dear Devananda
>>
>>   I'm the development leader of Lenovo Cloud Solution. Lenovo is
>> planning to contribute its Ironic driver to the OpenStack community. The
>> Ironic driver developers already registered as OpenStack members and
>> signed agreement with OpenStack org.
>>
>>   Sorry for broadcasting the message, but seems we have issue
>> sending mails to GMail account from China. Devananda, do you have
>> alternative mail for follow-up communication? Thanks.

Welcome!

>
>
> Hi!
>
> I'm adding [Ironic] tag to your message, so that our mail filters mark it as
> belonging to Ironic.
>
> Of course I can't answer for Devananda, but I think you can go ahead with
> proposing a spec [1] for your driver, see some already approved spec (e.g.
> [2] and [3]) for example. Drop by our IRC channel #openstack-ironic on
> Freenode if you have urgent questions to the team, or post here with
> [Ironic] tag.
>
> Thanks.
>
> [1] https://wiki.openstack.org/wiki/Ironic/Specs_Process
> [2]
> http://specs.openstack.org/openstack/ironic-specs/specs/liberty/msft-ocs-power-driver.html
> [3]
> http://specs.openstack.org/openstack/ironic-specs/specs/liberty/cisco-ucs-pxe-driver.html
>

+1, I don't know if it will be your first contribution with OpenStack
but you might want to take a look at the OpenStack guide for first
time developers [1]

And as Dmitry already pointed out, feel free to join in the
#openstack-ironic IRC channel and ask questions there as well!

[1] http://docs.openstack.org/infra/manual/developers.html#starting-a-change

Cheers,
Lucas

__
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

Re: [openstack-dev] [OpenStack-Infra] [all][infra] CI System is broken

[Andreas Jaeger]

On 2015-07-30 07:08, Ian Wienand wrote:

On 07/29/2015 07:33 PM, Andreas Jaeger wrote:

Currently Zuul is stuck and not processing any events at all, thus no
jobs are checked or gated.


I think whatever happened has happened again; if jhesketh is out it
might be a few hours from this email before people with the right
access are back online to fix it.


Joshua just restarted Zuul and is currently requeueing the jobs that 
were in the system.


Please check http://status.openstack.org/zuul whether your job is in the 
queues before you recheck it. We have a *very* long queue and thus avoid 
extra rechecks. It might be that some jobs from the last few hours were 
not enqueued and Zuul might have lost the events,


Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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

Re: [openstack-dev] [Ironic] Lenovo driver submission requests

[Dmitry Tantsur]

On 07/30/2015 08:59 AM, Kai KH Huang wrote:

Dear Devananda

  I'm the development leader of Lenovo Cloud Solution. Lenovo is
planning to contribute its Ironic driver to the OpenStack community. The
Ironic driver developers already registered as OpenStack members and
signed agreement with OpenStack org.

  Sorry for broadcasting the message, but seems we have issue
sending mails to GMail account from China. Devananda, do you have
alternative mail for follow-up communication? Thanks.


Hi!

I'm adding [Ironic] tag to your message, so that our mail filters mark 
it as belonging to Ironic.


Of course I can't answer for Devananda, but I think you can go ahead 
with proposing a spec [1] for your driver, see some already approved 
spec (e.g. [2] and [3]) for example. Drop by our IRC channel 
#openstack-ironic on Freenode if you have urgent questions to the team, 
or post here with [Ironic] tag.


Thanks.

[1] https://wiki.openstack.org/wiki/Ironic/Specs_Process
[2] 
http://specs.openstack.org/openstack/ironic-specs/specs/liberty/msft-ocs-power-driver.html
[3] 
http://specs.openstack.org/openstack/ironic-specs/specs/liberty/cisco-ucs-pxe-driver.html




/Best regards,/

*Huang Kai  (**黄凯**)*
OpenStack & VDI Leader
EBG System Software Solutions



**
huangk...@lenovo.com
Ph: +86 18116117520
VOIP: 021-20590074



Description: Lenovo-For-Those-Who-Do

*From:*Devananda van der Veen [mailto:devananda@gmail.com]
*Sent:* Tuesday, July 21, 2015 7:30 AM
*To:* OpenStack Development Mailing List
*Subject:* [openstack-dev] [Ironic] No meeting tonight?

Hi all,

My apologies, but I won't be able to attend the IRC meeting tonight.

The agenda is very light (basically non-existent) so I suggest that we
just cancel it and meet next Monday.

Also, I haven't seen any response to my email (*) from one week ago
about the lack of attendance to this (late night for the US) meeting
time from the very folks who this meeting is supposed to serve.

Thanks,

Devananda

(*) http://lists.openstack.org/pipermail/openstack-dev/2015-July/069363.html



__
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 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-dev] [tricircle] DAL implementation

[Vega Cai]

Hi folks,

In my current implementation, there are a core module and a models module.
Core module handles all the database stuff, start a session, issue sql
operation, then end a session. Models module invokes methods in core module
to access database, as showed below:

model.py
def get_site(site_id):
core.get_resource(Site, site_id)

core.py
def get_resource(model, pk_value):
# code to access database

To add context, I am going to implement like this:

model.py
def get_site(context, site_id):
policy_check(context)
core.get_resource(Site, site_id)

core.py
def get_resource(model, pk_value):
# code to access database

So there is no need to embed session into context.

One advantage of embedding session into context is that you can combine
more than one method calls in one session, like:

model.py
def complex_operation(context):
policy_check(context)
with context.session.begin():
core.operation1(context)
core.operation2(context)

But this approach moves session handling from core module to models module
and core module just provides some utility methods.

I'm not sure which one is better.

BR
Zhiyuan
__
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-dev] Lenovo driver submission requests

[Kai KH Huang]

Dear Devananda
 I'm the development leader of Lenovo Cloud Solution. Lenovo is 
planning to contribute its Ironic driver to the OpenStack community. The Ironic 
driver developers already registered as OpenStack members and signed agreement 
with OpenStack org.

 Sorry for broadcasting the message, but seems we have issue sending 
mails to GMail account from China. Devananda, do you have alternative mail for 
follow-up communication? Thanks.


Best regards,
Huang Kai  (黄凯)
OpenStack & VDI Leader
EBG System Software Solutions


huangk...@lenovo.com
Ph: +86 18116117520
VOIP: 021-20590074

[Description: Lenovo-For-Those-Who-Do]



From: Devananda van der Veen [mailto:devananda@gmail.com]
Sent: Tuesday, July 21, 2015 7:30 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Ironic] No meeting tonight?

Hi all,

My apologies, but I won't be able to attend the IRC meeting tonight.

The agenda is very light (basically non-existent) so I suggest that we just 
cancel it and meet next Monday.

Also, I haven't seen any response to my email (*) from one week ago about the 
lack of attendance to this (late night for the US) meeting time from the very 
folks who this meeting is supposed to serve.

Thanks,
Devananda

(*) http://lists.openstack.org/pipermail/openstack-dev/2015-July/069363.html


__
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