Re: [openstack-dev] [puppet] adding puppet-rally to OpenStack

[Andy Botting]

Hi Emillien,


> I think we would love having this module part of OpenStack, if it's ok
> for you.
>
> The process to move it is documented [1] but I can take care of it if
> you prefer, just let me know.
>
> Thanks for your collaboration, we're looking forward to have
> puppet-rally part of our forge.
>

I think I've followed the technical part of that document, but if you
wouldn't mind handing the rest, that would be great.

I'm glad this work will be of use to the rest of the community :)

cheers,
Andy
__
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] [horizon][infra] django.pot hardcoded or not?

[Andreas Jaeger]

On 12/30/2015 11:27 PM, Clark Boylan wrote:

The problem with using a tox target is that we use privileged Jenkins
machines to do the extraction and don't want arbitrary code to run on
them. It would be possible to run arbitrary code if we used a tox
target.


Clark, we run already "run_messages.sh --makemessages", isn't that 
already a problem?


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

[openstack-dev] [openstack][glance] add new property to image

[suresh knv]

Hi,

I am trying to run Openstack on ARM64 architecture. ARM64 architecture
with KVM hypervisor needs  GIC version(generic interrupt controller)
as a property for the image when we are creating/uploading an image. I
would like to include this property in the glance code. I am new to
glance, Can someone suggest me how to approach for this.


Thanks
Suresh KN V

__
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 add feature to diskimage-builder

[Clint Byrum]

Excerpts from George Shuklin's message of 2015-12-29 09:16:52 -0800:
> Hello.
> 
> I'm trying add a small feature to one of the elements in 
> diskimage-builder (https://github.com/openstack/diskimage-builder/pull/10/)
> 
> I have experience with gerrit and openstack bugfix workflow, but I have 
> no idea how to add small enhancements.
> 
> Dev guide says I need to add blueprint (how?) and follow the guides for 
> the project. But I can't find any dev guides specific for diskimage-builder.
> 
> What should I do? (Or may be I can just submit changes for review 
> without noting blueprint/spec?).
> 

If a feature can be completed with a small amount of patches, we don't
need a spec IMO. Specs are more about building community consensus
around _big_ changes that may affect many users or have large
cross-cutting ripple effects in the code.

Looking at your patch, I'd expect that with some adjustments via the
normal review process it would be accepted as-is.

__
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] [horizon][infra] django.pot hardcoded or not?

[Andreas Jaeger]

I'm currently looking into simplifying and consolidation of translation 
setup for projects (draft spec at [1]) and have a question for dashboard 
translations. Right now, horizon uses django.pot and djangojs.pot - and 
most *-dashboard projects use the same names. Are these names enforced 
by the django framework and thus cannot be changed or are they setup in 
our repositories this way and thus could be changed?


I prefer to rename them to make it clearer which project they belong to 
as part of my spec and would like your input on whether that's feasible.


Note: Once the spec is fleshed out, I'll send another email asking for 
review...


Andreas

References:
[1] https://review.openstack.org/262545

--
 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, 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] [horizon][infra] django.pot hardcoded or not?

[Akihiro Motoki]

I haven't looked into the code detail, but as far as I read
https://docs.djangoproject.com/en/1.9/topics/i18n/translation/#specialties-of-django-translation
it is enforced by django framework.

How django searches message catalogs is described at
https://docs.djangoproject.com/en/1.9/topics/i18n/translation/#how-django-discovers-translations.
In addition, django requires separate string domains for python part
and JavaScript part.

I don't think it is easy to change this.

I think it is better to define a tox target to extract message catalogs
instead of using "tox -e venv - ".

Akihiro


2015-12-31 0:42 GMT+09:00 Andreas Jaeger :
> I'm currently looking into simplifying and consolidation of translation
> setup for projects (draft spec at [1]) and have a question for dashboard
> translations. Right now, horizon uses django.pot and djangojs.pot - and most
> *-dashboard projects use the same names. Are these names enforced by the
> django framework and thus cannot be changed or are they setup in our
> repositories this way and thus could be changed?
>
> I prefer to rename them to make it clearer which project they belong to as
> part of my spec and would like your input on whether that's feasible.
>
> Note: Once the spec is fleshed out, I'll send another email asking for
> review...
>
> Andreas
>
> References:
> [1] https://review.openstack.org/262545
>
> --
>  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, 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

__
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] [puppet] [neutron] Serious bug in puppet neutron cli json output parsing.

[Sofer Athlan-Guyot]

Hi,

I have added neutron people as they may help to find a solution.

After banging my head against the wall for a whole afternoon I
discovered a serious bug in puppet neutron module.

I not going to repeat here the detail of the bug report[1].  Basically:
 - neutron_port
 - neutron_subnet
 - neutron_router
 - neutron_network

may break idempotency randomly and won't work at all when clifftablib is
removed from the package dependency of python-openstackclient
(Mitaka[2])

So the problem is that neutron cli json output on liberty (at least, and
maybe before) is not consistent and may come from cliff or clifftablib.
I didn't test it but the same may apply to openstack cli. As we don't
use the openstack cli json output it's not a issue (for puppet modules)

The available solution I can see are:
 1. go back to parsing csv, shell output (revert [3])
 2. find a way to leverage openstacklib parsing for neutron as well
 3. keep json and parse the right output (cliff) and find a way to make
sure that it is always used by stevedore
 4. ?

>From my point of view 3) is not a option, but other may disagree.

The problem is tricky and the fact that the CI cannot detect this is
trickier[4].

So before Mitaka, the json parsing should go.  I would love to see an
interface that all puppet modules would use (solution 2).  The current
openstacklib parses openstack client well enough.  The neutron command
is not that different and I think there is space for code reuse.  This
would be a long term solution.  It would bring the advantage of having
only one interface to change if it was decided to use the API directly
for instance[5]

In the meantime, a quick solution to this bug must be found.

Looking forward to your comments.

Regards,

[1] https://bugs.launchpad.net/puppet-neutron/+bug/1530163
[2] https://bugs.launchpad.net/python-neutronclient/+bug/1529914
[3] https://review.openstack.org/#/c/238156/
[4] https://review.openstack.org/#/c/262223/
[5] http://lists.openstack.org/pipermail/openstack-dev/2015-October/076439.html
-- 
Sofer Athlan-Guyot

__
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][Glance] Xenplugin + Glance_v2 = Hate

[Bob Ball]

Hi Mikhail,

Unfortunately I completely agree that using Glance with the XenServer plugin is 
painful.  As Keven pointed out, the current release of XenServer includes 
python 2.4 in dom0 (where the plugin runs) so having a dependency on nova.image 
or glanceclient is likely to introduce more pain than it might solve.

I would prefer approach 2; if we can reduce the amount of logic in the glance 
plugin and move it into the XenAPI driver in Nova then I think that would be a 
very good thing.

We would, of course, be interested in helping fix the plugin to support glance 
v2, so we should sync up on IRC in the new year (bobball)

Bob


From: Mikhail Fedosin [mfedo...@mirantis.com]
Sent: 24 December 2015 13:51
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Nova][Glance] Xenplugin + Glance_v2 = Hate

Hello! As you may know there is a big initiative to adopt glance v2 api in Nova 
and the important part is making related changes in xenglugin.
Unfortunately xenplugin doesn't use neither nova.image api nor glanceclient. 
Instead of this it has own http client implementation and bunch of hardcoded 
'v1' urls (example, 
https://github.com/openstack/nova/blob/master/plugins/xenserver/xenapi/etc/xapi.d/plugins/glance#L130).
 It leads to the fact, that it will be really hard to switch it on v2 api right.

Personally I see 2 solutions:
1. Make xenplugin to adopt nova.image api, which will make it version-agnostic. 
Here it's not easy to implement and we won't be able to keep backward 
compatibility with the existing lowlevel code.
2. Also hardcode v2 urls on par with v1 and do the same thing as in nova.image 
- to determine current glance api version before request and then use 
appropriate urls in methods.

IMHO, the second solution is more preferable, because I understand how to do it 
and the v1/v2 compatibility will be 100%. It guarantees that we won't break any 
of existing deployments and it will allow to merge glance_v2 code in nova.image 
much quicker.

All opinions and advice will be very helpful. Thanks in advance!

--
Best regards,
Mikhail Fedosin
__
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] [release][openstack] os-client-config release 1.13.1 (mitaka)

[doug]

We are thrilled to announce the release of:

os-client-config 1.13.1: OpenStack Client Configuation Library

This release is part of the mitaka release series.

With package available at:

https://pypi.python.org/pypi/os-client-config

For more details, please see below.



Changes in os-client-config 1.13.0..1.13.1
--

17e019a Munge region_name to '' if set to None
7be6db8 Fix some README typos
77c0365 Fix token_endpoint usage
f765a16 remove python 2.6 os-client-config classifier
8fa5570 If cloud doesn't list regions expand passed name

Diffstat (except docs and test files)
-

README.rst|  8 ++---
os_client_config/config.py| 18 +++---
setup.cfg |  1 -
5 files changed, 91 insertions(+), 12 deletions(-)



__
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] [nova][cinder] Deprecating ConfKeyManager (fixed-key key manager)

[Farr, Kaitlin M.]

All,

Please reply or send me an email if you are using the ConfKeyManager
(fixed-key key manager) in deployment for volume encryption or
ephemeral storage encryption. You can check this by looking at the
[keymgr] section, api_class entry of nova.conf or cinder.conf. The
ConfKeyManager was only intended for testing and I am working on
deprecating it. I would like to gauge the number of people using
that backend, because it may affect the deprecation strategy.

This is the start of the effort to replace the duplicated key manager
code with Castellan [1], a key manager interface library that allows
the user to swap out different backends, such as Barbican. While
Castellan is based on the key managers built into Nova and Cinder, it
does not have the fixed-key backend. That backend is insecure. A single
key is used for all volumes. If the key is compromised, all of the
encrypted data is easily decrypted. See Joel Coffman's comments on the
Nova spec [2]. Deprecating the fixed-key key manager would need to
occur before Castellan is integrated.

Again, please let me know if you use the ConfKeyManager and you
actively use the volume encryption and encrypted cinder volume features
in a deployment

Other feedback is also welcome.

I am also creating a separate thread with this info on the operators
mailing list.

Thanks,

Kaitlin Farr

1. Castellan source code. https://github.com/openstack/castellan
2. Castellan integration Nova spec. https://review.openstack.org/#/c/247561/
3. Castellan integration Cinder spec. https://review.openstack.org/#/c/247577/

__
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] [neutron] Serious bug in puppet neutron cli json output parsing.

[Colleen Murphy]

On Wed, Dec 30, 2015 at 8:37 AM, Sofer Athlan-Guyot 
wrote:

> Hi,
>
> I have added neutron people as they may help to find a solution.
>
> After banging my head against the wall for a whole afternoon I
> discovered a serious bug in puppet neutron module.
>
> I not going to repeat here the detail of the bug report[1].  Basically:
>  - neutron_port
>  - neutron_subnet
>  - neutron_router
>  - neutron_network
>
> may break idempotency randomly and won't work at all when clifftablib is
> removed from the package dependency of python-openstackclient
> (Mitaka[2])
>
> So the problem is that neutron cli json output on liberty (at least, and
> maybe before) is not consistent and may come from cliff or clifftablib.
> I didn't test it but the same may apply to openstack cli. As we don't
> use the openstack cli json output it's not a issue (for puppet modules)
>
> The available solution I can see are:
>  1. go back to parsing csv, shell output (revert [3])
>  2. find a way to leverage openstacklib parsing for neutron as well
>  3. keep json and parse the right output (cliff) and find a way to make
> sure that it is always used by stevedore
>  4. ?
>
> Last I checked, which was quite a while ago, openstackclient didn't
support everything we were using from the neutron client. I would like to
reevaluate that and go with option 2 if we can. Otherwise option 1 seems
reasonable.


> From my point of view 3) is not a option, but other may disagree.
>
> The problem is tricky and the fact that the CI cannot detect this is
> trickier[4].
>
> So before Mitaka, the json parsing should go.  I would love to see an
> interface that all puppet modules would use (solution 2).  The current
> openstacklib parses openstack client well enough.  The neutron command
> is not that different and I think there is space for code reuse.  This
> would be a long term solution.  It would bring the advantage of having
> only one interface to change if it was decided to use the API directly
> for instance[5]
>
> In the meantime, a quick solution to this bug must be found.
>
> Looking forward to your comments.
>
> Regards,
>
> [1] https://bugs.launchpad.net/puppet-neutron/+bug/1530163
> [2] https://bugs.launchpad.net/python-neutronclient/+bug/1529914
> [3] https://review.openstack.org/#/c/238156/
> [4] https://review.openstack.org/#/c/262223/
> [5]
> http://lists.openstack.org/pipermail/openstack-dev/2015-October/076439.html
> --
> Sofer Athlan-Guyot
>
> Colleen
__
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] Separate master node provisioning and deployment

[Vitaly Parakhin]

Dear colleagues,

The spec for this feature is ready for review [0], so I'd like to encourage
all the parties concerned in Fuel modularization to participate.

Thanks

[0] https://review.openstack.org/#/c/254270/


On Fri, Dec 11, 2015 at 9:45 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> At the moment part of the Fuel master deployment logic is located in ISO
> kickstart file, which is bad. We'd better carefully split provisioning and
> deployment stages so as to install base operating system during
> provisioning stage and then everything else on the deployment stage. That
> would make it possible to deploy Fuel on pre-installed vanilla Centos 7.
> Besides, if we have deb packages for all Fuel components it will be easy to
> support Fuel deployment on pre-installed Ubuntu and Debian.
>
> We (Fuel build team) are going to do this ASAP [0]. Right now we are on
> the stage of writing design spec for the change [1].
>
> Open questions are:
> 1) Should fuel package have all other fuel packages like nailgun, astute,
> etc. as its dependencies? Or maybe it should install only puppet modules
> and deployment script that then could be used to deploy everything else?
>
> 2) bootstrap_admin_node.sh runs fuelmenu and then puppet to deploy Fuel
> components. Should we run this script as post-install script or maybe we
> should leave this up to a user to run this script later when fuel package
> is already installed?
>
> Anyway, the final goal is to make ISO just one of possible delivery
> schemes. Primary delivery approach should be rpm/deb repo, not ISO.
>
> [0]
> https://blueprints.launchpad.net/fuel/+spec/separate-fuel-node-provisioning
> [1] https://review.openstack.org/#/c/254270/
>
> Vladimir Kozhukalov
>
> __
> 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
>
>


-- 
Regards,
Vitaly Parakhin.
Infra Build Engineer | Mirantis, Inc. | http://www.mirantis.com
IRC: brain461 @ chat.freenode.net | Slack: vparakhin
__
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] github can't sync with git because of big uploading

[Evgeniy L]

Hi,

You should probably talk to infra team on this issue #openstack-infra
channel.
I see several ways what can be done here:
1. recreate the repo
2. create a repo with different name

Also there is possibility to remove from the commit those files and push
using --force,
but it's a very bad practise and I don't think that infra allows to do that.

Thanks,

On Wed, Dec 30, 2015 at 5:34 AM, wuwenbin  wrote:

> Hi all:
>
>  Repo of fuel-plugin-onos has something wrong because of uploading
> big file. Though codes are reverted while history still contains the pack
> which results in big downloading and unsync with github.
>
>  I really want to solve this problem and please forgive my own
> decision for a new commit of new onosfw because I don’t want this impacting
> the project. I have to admit that I am really bad at management of commit
> and merge. So I invite fuel ptl as the manager of new repo to avoid such
> things.
>
>  Does anyone can help me solve this as soon as possible?
>
>Thanks
>
> Bests
>
> 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
>
>
__
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] Adding Ubuntu Liberty to Kolla-Mitaka

[Canonical Calendar]

> On 30 Dec 2015, at 07:25, Michal Rostecki  wrote:
> 
>> On 12/30/2015 03:17 AM, Lei Zhang wrote:
>> Why the package is still the nova 12.0.0 rather than 13.0.0 ? [0]
>> Most the package is updated at Nov 9, 2015. But it is almost 2016 now.
>> 
>> [0]
>> http://ppa.launchpad.net/ubuntu-cloud-archive/mitaka-staging/ubuntu/pool/main/n/nova/
> 
> I see that the most of packages from that repo are in Liberty version. The 
> same situation is i.e. with neutron (7.0.0)[0], heat (5.0.0)[1], glance 
> (11.0.0).
> 
> On the other hand, cinder (8.0.0, 24th Dec)[3] seems to be from Mitaka.
> 
> If the default services used by kolla[4] will be packaged from Mitaka, it 
> would be nice to switch to mitaka-staging - at least IMO it'd be still better 
> than using Liberty packages. But for now, it's impossible.

The Mitaka 1 update is still in progress - it ran into the start of the holiday 
period so right now will be a mix of releases.

I'd expect that to be sorted out by the end of next week when the packaging 
team get back post new year

For reference these are links that might be more accessible for referencing 
versions

https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/mitaka-staging

> 
> [0] 
> http://ppa.launchpad.net/ubuntu-cloud-archive/mitaka-staging/ubuntu/pool/main/n/neutron/
> [1] 
> http://ppa.launchpad.net/ubuntu-cloud-archive/mitaka-staging/ubuntu/pool/main/h/heat/
> [3] 
> http://ppa.launchpad.net/ubuntu-cloud-archive/mitaka-staging/ubuntu/pool/main/c/cinder/
> [4] 
> https://github.com/openstack/kolla/blob/master/etc/kolla/kolla-build.conf#L64
> 
> Cheers,
> Michal
> 
> __
> 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] [Nailgun] Deadlocks and random test failures

[Alexander Kislitsky]

Hi, guys.

Igor is absolutelly right - there are no deadlocks. We have only warnings
from detector, but they caused by difference between actual locking order
in the code and allowed by detector. It is annoying, but detection is used
only in development environment, thus it is not high bug.

When DB deadlock occurs we have ShareLock exception in the logs and it
raised before detector warning. So we always have deadlock exception in the
logs if it occurs.
I think tests failures are caused by another issue. As I can see we have a
set of random failures in the tests now and bugs on it:

https://bugs.launchpad.net/fuel/+bug/1437232
https://bugs.launchpad.net/fuel/+bug/1502908
https://bugs.launchpad.net/fuel/+bug/1518268
https://bugs.launchpad.net/fuel/+bug/1521966

We should focus on fixing these bugs. Could you please help us with
detection of the root cause of UI tests failures? May be we have another
floating bug in tests.

On Wed, Dec 30, 2015 at 4:11 PM, Igor Kalnitsky 
wrote:

> Hey Vitaly,
>
> Are you the problem is in deadlock? I see the deadlock detecter
> traceback, but not an actual deadlock.
>
> I'm not sure could it be a reason for failure or not, it's better to
> ask Alexander Kislitsky.
>
> Thanks,
> Igor
>
> On Wed, Dec 30, 2015 at 2:57 PM, Vitaly Kramskikh
>  wrote:
> > Hi,
> >
> > We have a long-living issue with deadlocks in nailgun which used to
> almost
> > harmless and caused rare test failures. But test failures become more
> > frequent and today there is ~20% probability that they will fail on a
> > working code, which is really annoying. Moreover, a few weeks ago it
> started
> > to affect UI functional tests: cluster reset task may hang, so this issue
> > now may affect real deployments.
> >
> > I think we need to do something with it ASAP.
> >
> > --
> > Vitaly Kramskikh,
> > Fuel UI Tech Lead,
> > Mirantis, 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
> >
>
> __
> 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] Adding Ubuntu Liberty to Kolla-Mitaka

[Michal Rostecki]

On 12/30/2015 11:07 AM, Canonical Calendar wrote:


The Mitaka 1 update is still in progress - it ran into the start of the
holiday period so right now will be a mix of releases.

I'd expect that to be sorted out by the end of next week when the
packaging team get back post new year

For reference these are links that might be more accessible for
referencing versions

https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/mitaka-staging



Thank you, James! Good news. We'll be waiting then.

Cheers,
Michal

__
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] github can't sync with git because of big uploading

[Jeremy Stanley]

On 2015-12-30 02:34:32 + (+), wuwenbin wrote:
> Repo of fuel-plugin-onos has something wrong because of uploading
> big file. Though codes are reverted while history still contains
> the pack which results in big downloading and unsync with github.
[...]

The OpenStack Project does not officially endorse, much less
support, GitHub-based workflows. That's a non-free, non-open service
over which we have neither control nor even insight most of the
time.

OpenStack provides Git services at git.openstack.org and only pushes
copies to other providers as a convenience for some users who seem
to like them indexed there. As for the repository size, we already
have much larger repositories in Gerrit than yours
(openstack-manuals, for example).

> Does anyone can help me solve this as soon as possible?

As suggested to you in IRC last week, clone from git.openstack.org
instead of github.com and you can continue working as usual. While
the Infrastructure Team is discussing lowering the object size limit
in our Gerrit deployment, we have no control over what else GitHub
might also block (now or in the future) and so can't guarantee any
repository will be mirrored there with 100% certainty.

Once more of the Infra team are back from holiday travels, I'll get
a better consensus on whether pushing a rewritten master branch to
fuel-plugin-onos is a viable compromise we're able to support in
situations like this, but please stop thinking that there's
something broken. The systems we support are working as designed,
and you should still be able to use them for your existing project
without having to abandon it and create a new one under a different
name.
-- 
Jeremy Stanley


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] [Fuel] [Nailgun] Deadlocks and random test failures

[Igor Kalnitsky]

Hey Vitaly,

Are you the problem is in deadlock? I see the deadlock detecter
traceback, but not an actual deadlock.

I'm not sure could it be a reason for failure or not, it's better to
ask Alexander Kislitsky.

Thanks,
Igor

On Wed, Dec 30, 2015 at 2:57 PM, Vitaly Kramskikh
 wrote:
> Hi,
>
> We have a long-living issue with deadlocks in nailgun which used to almost
> harmless and caused rare test failures. But test failures become more
> frequent and today there is ~20% probability that they will fail on a
> working code, which is really annoying. Moreover, a few weeks ago it started
> to affect UI functional tests: cluster reset task may hang, so this issue
> now may affect real deployments.
>
> I think we need to do something with it ASAP.
>
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> Mirantis, 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
>

__
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] github can't sync with git because of big uploading

[Jeremy Stanley]

On 2015-12-30 11:11:50 +0300 (+0300), Evgeniy L wrote:
> You should probably talk to infra team on this issue #openstack-infra
> channel.
> I see several ways what can be done here:
> 1. recreate the repo
> 2. create a repo with different name
> 
> Also there is possibility to remove from the commit those files and push
> using --force,
> but it's a very bad practise and I don't think that infra allows to do that.

While I'm not a fan of push --force based solutions (they leave the
repository in a state where consumers can't fast-forward to it from
their earlier state), I'm even less thrilled with the idea that
people might just slash-and-burn repos, abandoning them and creating
new ones because they've put them in an unusable state.
-- 
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

[openstack-dev] [Fuel] [Nailgun] Deadlocks and random test failures

[Vitaly Kramskikh]

Hi,

We have a long-living issue with deadlocks in nailgun which used to almost
harmless and caused rare test failures. But test failures become more
frequent and today there is ~20% probability that they will fail on a
working code, which is really annoying. Moreover, a few weeks ago it
started to affect UI functional tests: cluster reset task may hang
, so this issue now may
affect real deployments.

I think we need to do something with it ASAP.

-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, 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] [Fuel] [Nailgun] Deadlocks and random test failures

[Vitaly Kramskikh]

Alexander,

Thanks for the response.

As for tasks hanging bug, I removed "deadlock" from its title: there is
another exception, which I didn't find due to huge number of traces from
deadlock detector.

As for random test failures bugs, I totally agree we should focus on them.
Just look at this: https://review.openstack.org/#/c/262183/ - I ran
"recheck" 5 times, rebased on master 1 time and still no luck: sometimes I
get -1 from Jenkins, sometimes from Fuel CI. I think this is a Critical
issue.

2015-12-30 16:39 GMT+03:00 Alexander Kislitsky :

> Hi, guys.
>
> Igor is absolutelly right - there are no deadlocks. We have only warnings
> from detector, but they caused by difference between actual locking order
> in the code and allowed by detector. It is annoying, but detection is used
> only in development environment, thus it is not high bug.
>
> When DB deadlock occurs we have ShareLock exception in the logs and it
> raised before detector warning. So we always have deadlock exception in the
> logs if it occurs.
> I think tests failures are caused by another issue. As I can see we have a
> set of random failures in the tests now and bugs on it:
>
> https://bugs.launchpad.net/fuel/+bug/1437232
> https://bugs.launchpad.net/fuel/+bug/1502908
> https://bugs.launchpad.net/fuel/+bug/1518268
> https://bugs.launchpad.net/fuel/+bug/1521966
>
> We should focus on fixing these bugs. Could you please help us with
> detection of the root cause of UI tests failures? May be we have another
> floating bug in tests.
>
> On Wed, Dec 30, 2015 at 4:11 PM, Igor Kalnitsky 
> wrote:
>
>> Hey Vitaly,
>>
>> Are you the problem is in deadlock? I see the deadlock detecter
>> traceback, but not an actual deadlock.
>>
>> I'm not sure could it be a reason for failure or not, it's better to
>> ask Alexander Kislitsky.
>>
>> Thanks,
>> Igor
>>
>> On Wed, Dec 30, 2015 at 2:57 PM, Vitaly Kramskikh
>>  wrote:
>> > Hi,
>> >
>> > We have a long-living issue with deadlocks in nailgun which used to
>> almost
>> > harmless and caused rare test failures. But test failures become more
>> > frequent and today there is ~20% probability that they will fail on a
>> > working code, which is really annoying. Moreover, a few weeks ago it
>> started
>> > to affect UI functional tests: cluster reset task may hang, so this
>> issue
>> > now may affect real deployments.
>> >
>> > I think we need to do something with it ASAP.
>> >
>> > --
>> > Vitaly Kramskikh,
>> > Fuel UI Tech Lead,
>> > Mirantis, 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
>> >
>>
>> __
>> 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
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, 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

[openstack-dev] Should Cinder have a volume_action table to track changes on a Volume?

[SCHVENINGER, DOUGLAS P]

I was looking into a support issue and noticed that Nova has an instance and 
instance_action table. I was wondering if this is something that cinder would 
consider adding a volume_action table to track changes to a volume?

I looked in the specs and I could not see anything like this.

Has this been talked about before?

Does this sound like something cinder would like to add?

Doug Schveninger
Principal Technical Architect
AIC - AT Integrated Cloud
AT Services, Inc.
Rethink Possible

Email: ds6...@att.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] Should Cinder have a volume_action table to track changes on a Volume?

[Duncan Thomas]

Cinder already emits events on all volume actions, and there are a few
projects that do various things with this info (e.g. stacktach). What do
you think the advantages of doing this inside cinder would be?

On 30 December 2015 at 16:54, SCHVENINGER, DOUGLAS P  wrote:

> I was looking into a support issue and noticed that Nova has an instance
> and instance_action table. I was wondering if this is something that cinder
> would consider adding a volume_action table to track changes to a volume?
>
> I looked in the specs and I could not see anything like this.
>
> Has this been talked about before?
>
> Does this sound like something cinder would like to add?
>
>
>
> Doug Schveninger
>
> Principal Technical Architect
>
> AIC – AT Integrated Cloud
>
> *AT* Services, Inc.
>
> *Rethink Possible*
>
>
>
> Email: ds6...@att.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
>
>


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