Re: [openstack-dev] [Rally] Deployment check fails
Hi!
Sorry for such a not user-friendly error message. Several days ago, we
merged a fix[*] for it and I'm planning to release a new version of
rally-openstack package soon.
While the fix is not released, please share the result of the 2 commands:
- rally env show --only-spec # replace password and etc
- rally env info
[*] -
https://github.com/openstack/rally-openstack/commit/5821f8b8714c532778f2eef142a5fdeb3a1e6f05
пт, 31 авг. 2018 г. в 17:02, Sai Sindhur Malleni :
> Hey all,
>
> rally deployment check fails saying, bad admin credentials but I'm able to
> use the admin tenant to performance openstack operations like creating VMs
> extra. rally deployment check fails without giving much information.
> (.rally-venv) [stack@undercloud browbeat]$ rally deployment check
>
>
> Platform openstack:
>
>
>
> Error while checking admin credentials:
> AuthenticationFailed: Bad admin creds:
> {
> "auth_url": "https://10.0.0.5:13000//v3;,
> "domain_name": null,
> "endpoint_type": null,
> "https_cacert": "",
> "https_insecure": false,
> "password": "***",
> "profiler_conn_str": null,
> "profiler_hmac_key": null,
> "project_domain_name": "Default",
> "region_name": "",
> "tenant_name": "admin",
> "user_domain_name": "Default",
> "username": "admin"
> }
>
> I'm not sure that the reason is give I can source the adminrc and run
> openstack commands normally.
>
> Here are the contents of the rc file:
> for key in $( set | awk '{FS="="} /^OS_/ {print $1}' ); do unset $key ;
> done
> export OS_NO_CACHE=True
> export COMPUTE_API_VERSION=1.1
> export OS_USERNAME=admin
> export no_proxy=,10.0.0.5,192.168.24.7
> export OS_USER_DOMAIN_NAME=Default
> export OS_VOLUME_API_VERSION=3
> export OS_CLOUDNAME=overcloud
> export OS_AUTH_URL=https://10.0.0.5:13000//v3
> export NOVA_VERSION=1.1
> export OS_IMAGE_API_VERSION=2
> export OS_PASSWORD=kYbMNEdPwGfCBUrwDH4rdxZyJ
> export OS_PROJECT_DOMAIN_NAME=Default
> export OS_IDENTITY_API_VERSION=3
> export OS_PROJECT_NAME=admin
> export OS_AUTH_TYPE=password
> export PYTHONWARNINGS="ignore:Certificate has no, ignore:A true SSLContext
> object is not available"
>
> # Add OS_CLOUDNAME to PS1
> if [ -z "${CLOUDPROMPT_ENABLED:-}" ]; then
> export PS1=${PS1:-""}
> export PS1=\${OS_CLOUDNAME:+"(\$OS_CLOUDNAME)"}\ $PS1
> export CLOUDPROMPT_ENABLED=1
> fi
>
>
> Please let me know if there is a way to know more about what the issue is.
> --
> Sai Sindhur Malleni
>
> Software Engineer
> Red Hat Inc.
> 314 Littleton Road
> Westford MA, USA
>
>
--
Best regards,
Andrey Kurilin.
__
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 lagging behind 2 major python versions: we need a Python 3.7 gate
Hi Doug! I'm ready to port our job to openstack-zuul-jobs repo, but I expect that Community will not accept it. The result of rally unittests is different between environments with python 3.7 final release and python 3.7.0~b3 . There is at least one failed test at python 3.7.0~b3 which is not reproducible at py27,py34,py35,py36,py37-final , so I'm not sure that it is a good decision to add py37 job based on ubuntu-bionic. As for Rally, I applied the easiest thing which occurred to me - just use external python ppa (deadsnakes) to install the final release of Python 3.7. Such a way is satisfying for Rally community and it cannot be used as the main one for the whole OpenStack. ср, 8 авг. 2018 г. в 16:35, Doug Hellmann : > Excerpts from Andrey Kurilin's message of 2018-08-08 15:25:01 +0300: > > Thanks Thomas for pointing to the issue, I checked it locally and here is > > an update for openstack/rally (rally framework without in-tree OpenStack > > plugins) project: > > > > - added unittest job with py37 env > > It would be really useful if you could help set up a job definition in > openstack-zuul-jobs like we have for openstack-tox-py36 [1], so that other > projects can easily add the job, too. Do you have time to do that? > > Doug > > [1] > http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/zuul.d/jobs.yaml#n354 > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] [rally] There is no Platform plugin with name: 'existing@openstack'"
Hi Goutham! There are 2 issues which can result in such error: 1) You did not read change log for Rally (see https://github.com/openstack/rally/blob/master/CHANGELOG.rst, all versions are included there). We do not provide in-tree OpenStack plugins started from Rally 1.0.0 .You need to install rally-openstack package ( https://pypi.python.org/pypi/rally-openstack) . It has Rally as a dependency, so if you are preparing the environment from the scratch -> just install rally-openstack package. 2) There are one or many conflicts in package requirements. Run `rally plugin show Dummy.openstack` and see the logging messages. It should point out the errors of loading plugins if there is something. чт, 9 авг. 2018 г. в 10:32, Goutham Pratapa : > Hi Rally Team, > > I have been trying to setup rally version v1.1.0 > > I could successfully install rally but when i try to create the deployment > i am getting this error > > > > *ubuntu@ubuntu:~$ rally deployment create --file=existing.json > --name=existing* > > *Env manager got invalid spec:* > > > * ["There is no Platform plugin with name: 'existing@openstack'"]* > > > *ubuntu@ubuntu:~$ rally version * > > *1.1.0* > > can any one help me the issue and the fix ? > > Thanks in advance. > > -- > Cheers !!! > Goutham Pratapa > __ > 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 > -- Best regards, Andrey Kurilin. __ 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 lagging behind 2 major python versions: we need a Python 3.7 gate
Thanks Thomas for pointing to the issue, I checked it locally and here is an update for openstack/rally (rally framework without in-tree OpenStack plugins) project: - added unittest job with py37 env - fixed all issues - released a new version (1.1.0) As for the openstack/rally-openstack (rally plugins for OpenStack platform), I'm planning to do the same this week. пн, 6 авг. 2018 г. в 20:11, Thomas Goirand : > On 08/02/2018 10:43 AM, Andrey Kurilin wrote: > > There's also some "raise StopIteration" issues in: > > - ceilometer > > - cinder > > - designate > > - glance > > - glare > > - heat > > - karbor > > - manila > > - murano > > - networking-ovn > > - neutron-vpnaas > > - nova > > - rally > > > > > > Can you provide any traceback or steps to reproduce the issue for Rally > > project ? > > I'm not sure there's any. The only thing I know is that it has stop > StopIteration stuff, but I'm not sure if they are part of generators, in > which case they should simply be replaced by "return" if you want it to > be py 3.7 compatible. > > I didn't have time to investigate these, but at least Glance was > affected, and a patch was sent (as well as an async patch). None of them > has been merged yet: > > https://review.openstack.org/#/c/586050/ > https://review.openstack.org/#/c/586716/ > > That'd be ok if at least there was some reviews. It looks like nobody > cares but Debian & Ubuntu people... :( > > Cheers, > > Thomas Goirand (zigo) > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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 lagging behind 2 major python versions: we need a Python 3.7 gate
Hi Thomas! On Thu, 2 Aug 2018 at 06:13, Thomas Goirand wrote: > On 07/12/2018 10:38 PM, Thomas Goirand wrote: > > Hi everyone! > > > > [...] > Here's more examples that shows why we should be gating earlier with > newer Python versions: > > Nova: > https://review.openstack.org/#/c/584365/ > > Glance: > https://review.openstack.org/#/c/586716/ > > Murano: > https://bugs.debian.org/904581 > > Pyghmi: > https://bugs.debian.org/905213 > > There's also some "raise StopIteration" issues in: > - ceilometer > - cinder > - designate > - glance > - glare > - heat > - karbor > - manila > - murano > - networking-ovn > - neutron-vpnaas > - nova > - rally Can you provide any traceback or steps to reproduce the issue for Rally project ? > > - zaqar > > It'd be nice to have these addressed ASAP. > > Cheers, > > Thomas Goirand (zigo) > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] Ongoing spam in Freenode IRC channels
ср, 1 авг. 2018 г. в 15:37, Monty Taylor : > On 08/01/2018 06:22 AM, Luigi Toscano wrote: > > On Wednesday, 1 August 2018 12:49:13 CEST Andrey Kurilin wrote: > >> Hey Ian and stackers! > >> > >> ср, 1 авг. 2018 г. в 8:45, Ian Wienand : > >>> Hello, > >>> > >>> It seems freenode is currently receiving a lot of unsolicited traffic > >>> across all channels. The freenode team are aware [1] and doing their > >>> best. > >>> > >>> There are not really a lot of options. We can set "+r" on channels > >>> which means only nickserv registered users can join channels. We have > >>> traditionally avoided this, because it is yet one more barrier to > >>> communication when many are already unfamiliar with IRC access. > >>> However, having channels filled with irrelevant messages is also not > >>> very accessible. > >>> > >>> This is temporarily enabled in #openstack-infra for the time being, so > >>> we can co-ordinate without interruption. > >>> > >>> Thankfully AFAIK we have not needed an abuse policy on this before; > >>> but I guess we are the point we need some sort of coordinated > >>> response. > >>> > >>> I'd suggest to start, people with an interest in a channel can request > >>> +r from an IRC admin in #openstack-infra and we track it at [2] >>> > >>> Longer term ... suggestions welcome? :) > >> > >> Move to Slack? We can provide auto-sending to emails invitations for > >> joining by clicking the button on some page at openstack.org. It will > not > >> add more berrier for new contributors and, at the same time, this way > will > >> give some base filtering by emails at least. > > slack is pretty unworkable for many reasons. The biggest of them is that > it is not Open Source and we don't require OpenStack developers to use > proprietary software to work on OpenStack. > > The quality of slack that makes it effective at fighting spam is also > the quality that makes it toxic as a community platform - the need for > an invitation and being structured as silos. > > Even if we were to decide to abandon our Open Source principles and > leave behind those in our contributor base who believe that Free > Software Needs Free Tools [1] - moving to slack would be a GIANT > undertaking. As such, it would not be a very effective way to deal with > this current spam storm. > > > No, please no. If we need to move to another service, better go to a > FLOSS > > one, like Matrix.org, or others. > > We had some discussion in Vancouver about investigating the use of > Matrix. We are a VERY large community, so we need to do scale and > viability testing before it's even a worthy topic to raise with the TC > and the community for consideration. If we did, we'd aim to run our own > home server. > The last paragraph is the best answer why we never switch from IRC. "we are a VERY large community" Looking back at migration to Zuul V3: the project which is written by folks who know potencial high-load and usage, the project which has a great background. Some issues appeared only after launching it in production. Fortunately, Zuul-community quickly fixed them and we have this great CI system now. As for the FOSS alternatives for the Slack aka modern IRC, I did not heard anything scalable for the size we need. Also, in case of any issues, they will not be fixed as quickly as it was with Zull V3 (thank you folks!). Another issue, the alternative should be popular, modern and usable. IRC is the thing which is used by a lot of communities (i.e. you do not need to install some no-name tool to communicate for one more topic), the same for Slack and I suppose some other tools havethe same popularity (but I do not have installed versions of them). If the alternative doesn't feet these criteria, a lot of people will stay at Freenode and migration will fail. > However, it's worth noting that matrix is not immune to spam. As an open > federated protocol, it's a target as well. Running our own home server > might give us some additional tools - but it might not, and we might be > in the same scenario except now we're running another service and we had > the pain of moving. > > All that to say though, matrix seems like the best potential option > available that meets the largest number of desires from our user base. > Once we've checked it out for viability it might be worth discussing. > > As above, any effort there is a pretty giant one that will require a > large amount of planning, a pretty sizeable amount of technic
Re: [openstack-dev] [all] Ongoing spam in Freenode IRC channels
ср, 1 авг. 2018 г. в 14:11, Dmitry Tantsur : > On 08/01/2018 12:49 PM, Andrey Kurilin wrote: > > Hey Ian and stackers! > > > > ср, 1 авг. 2018 г. в 8:45, Ian Wienand > <mailto:iwien...@redhat.com>>: > > > > Hello, > > > > It seems freenode is currently receiving a lot of unsolicited traffic > > across all channels. The freenode team are aware [1] and doing their > > best. > > > > There are not really a lot of options. We can set "+r" on channels > > which means only nickserv registered users can join channels. We > have > > traditionally avoided this, because it is yet one more barrier to > > communication when many are already unfamiliar with IRC access. > > However, having channels filled with irrelevant messages is also not > > very accessible. > > > > This is temporarily enabled in #openstack-infra for the time being, > so > > we can co-ordinate without interruption. > > > > Thankfully AFAIK we have not needed an abuse policy on this before; > > but I guess we are the point we need some sort of coordinated > > response. > > > > I'd suggest to start, people with an interest in a channel can > request > > +r from an IRC admin in #openstack-infra and we track it at [2] > > > > Longer term ... suggestions welcome? :) > > > > > > Move to Slack? We can provide auto-sending to emails invitations for > joining by > > clicking the button on some page at openstack.org <http://openstack.org>. > It > > will not add more berrier for new contributors and, at the same time, > this way > > will give some base filtering by emails at least. > > A few potential barriers with slack or similar solutions: lack of FOSS > desktop > clients (correct me if I'm wrong), The second link from google search gives an opensource client written in python https://github.com/raelgc/scudcloud . Also, there is something which is written in golang. > complete lack of any console clients (ditto), > Again, google gives several ones as first results - https://github.com/evanyeung/terminal-slack https://github.com/erroneousboat/slack-term serious limits on free (as in beer) tariff plans. > > I can make an assumption that for marketing reasons, Slack Inc can propose extended Free plan. But anyway, even with default one the only thing which can limit us is `10,000 searchable messages` which is bigger than 0 (freenode doesn't store messages). Why I like slack? because a lot of people are familar with it (a lot of companies use it as like some opensource communities, like k8s ) PS: I realize that OpenStack Community will never go away from Freenode and IRC, but I do not want to stay silent. > > > -i > > > > [1] https://freenode.net/news/spambot-attack > > [2] https://etherpad.openstack.org/p/freenode-plus-r-08-2018 > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > < > http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > -- > > Best regards, > > Andrey Kurilin. > > > > > > > __ > > 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 > -- Best regards, Andrey Kurilin. __ 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] Ongoing spam in Freenode IRC channels
Hey Ian and stackers! ср, 1 авг. 2018 г. в 8:45, Ian Wienand : > Hello, > > It seems freenode is currently receiving a lot of unsolicited traffic > across all channels. The freenode team are aware [1] and doing their > best. > > There are not really a lot of options. We can set "+r" on channels > which means only nickserv registered users can join channels. We have > traditionally avoided this, because it is yet one more barrier to > communication when many are already unfamiliar with IRC access. > However, having channels filled with irrelevant messages is also not > very accessible. > > This is temporarily enabled in #openstack-infra for the time being, so > we can co-ordinate without interruption. > > Thankfully AFAIK we have not needed an abuse policy on this before; > but I guess we are the point we need some sort of coordinated > response. > > I'd suggest to start, people with an interest in a channel can request > +r from an IRC admin in #openstack-infra and we track it at [2] > > Longer term ... suggestions welcome? :) > > Move to Slack? We can provide auto-sending to emails invitations for joining by clicking the button on some page at openstack.org. It will not add more berrier for new contributors and, at the same time, this way will give some base filtering by emails at least. > -i > > [1] https://freenode.net/news/spambot-attack > [2] https://etherpad.openstack.org/p/freenode-plus-r-08-2018 > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] [rally][dragonflow][ec2-api][PowerVMStackers][murano] Tagging rights
Hi Sean! Thanks for raising this question. As for Rally team, we are using self-tagging approach for several reasons: - Release notes Check the difference between https://github.com/openstack/nova/releases/tag/17.0.2 and https://github.com/openstack/rally-openstack/releases/tag/1.0.0. The first one includes just autogenerated metadata. The second one user-friendly notes (they are not ideal, but we are working on making them better). I do not find a way to add custom release notes via openstack/releases project. - Time Self-tagging the repo allows me to schedule/reschedule the release in whatever timeframe I decide without pinging anyone and waiting for folks to return from summit/PTG. I do not want to offend anyone, but we all know that such events take much time for preparation, holding and resting after it. Since there are no official OpenStack projects built on top of Rally, launching any of "integration" jobs while making Rally release is a wasting of time and money(resources). Also, such jobs can block to make a release. I remember sometimes it can take weeks to pass all gates with tons of rechecks https://github.com/openstack/releases#release-approval == "Freezes and no late releases". It is an opensource and I want to make releases on weekends if there is any reason for doing this (critical fix or the last blocking feature is merged or whatever). 2018-04-13 22:53 GMT+03:00 Sean McGinnis <sean.mcgin...@gmx.com>: > On Fri, Apr 13, 2018 at 02:46:59PM -0500, Sean McGinnis wrote: > > Hello teams, > > > > I am following up on some recently announced changes regarding governed > > projects and tagging rights. See [1] for background. > > > > [1] https://review.openstack.org/#/c/557737/ > > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] [rally] Moving OpenStack plugins into separate repo
Hi Stackers! Today I am happy to announce great news! >From a historical perspective, Rally is testing (benchmarking) tool for OpenStack, but it is changed. More and more users want to use Rally for different platforms and environments. Our pluggable system allows doing this. To make the framework lightweight and simplify our release model, we decided to move OpenStack to the separate repository[1]. [1] https://git.openstack.org/cgit/openstack/rally-openstack We cut the first release 1.0.0 two weeks ago, and it is published to PyPI[2]. [2] https://pypi.python.org/pypi/rally-openstack If you are Rally consumer and do not have custom plugins, the migration should be simple. Just install rally-openstack package instead of rally and everything will work as previously. rally-openstack has a dependency to rally, so you need nothing more than installing one package. If you have custom plugins, do not worry, the migration should be simple for you too. The first release has the similar structure as it was in rally repository. The only thing which should be changed is importing rally_openstack instead of rally.plugins.openstack. -- Best regards, Andrey Kurilin. __ 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] Rocky community goal: remove the use of mox/mox3 for testing
Hi Melanie and stacker! This is a nice goal which revises me the first my patch to OpenStack community. It was a patch to Nova and it was related to removing mox :) PS: https://review.openstack.org/#/c/59694/ PS2: it was abandoned due to several -2 :) 2018-03-27 1:06 GMT+03:00 melanie witt <melwi...@gmail.com>: > Hey everyone, > > This cycle there is a community goal to remove the use of mox/mox3 for > testing [0]. In nova, we're tracking our work at this blueprint: > > https://blueprints.launchpad.net/nova/+spec/mox-removal > > If you propose patches contributing to this goal, please be sure to add > something like "Part of blueprint mox-removal" in the commit message of > your patch so it will be tracked as part of the blueprint for Rocky. > > NOTE: Please avoid converting any tests related to cells v1 or > nova-network as these two legacy features are either in-progress of being > removed or on the road map to being removed within the next two cycles. > Tests to *avoid* converting are located: > > nova/tests/unit/cells/ > nova/nova/tests/unit/compute/test_compute_cells.py > nova/tests/unit/network/test_manager.py > > Please reply with other cells v1 or nova-network test locations to avoid > if I've missed any. > > Thanks, > -melanie > > [0] https://storyboard.openstack.org/#!/story/2001546 > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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][neutron][openstackclient] The way to assign floating IPs to VM
Matt, thanks! Unfortunately, I missed your thread. Dean, I propose a patch (https://review.openstack.org/549820) which should work for all environments where neutron is installed. Please check it when you have free time. 2018-03-05 17:17 GMT+02:00 Dean Troyer <dtro...@gmail.com>: > On Mon, Mar 5, 2018 at 8:07 AM, Matt Riedemann <mriede...@gmail.com> > wrote: > > On 3/5/2018 6:26 AM, Andrey Kurilin wrote: > >> - openstackclient > >> > >> * command `openstack server add floating ip` calls `add_floating_ip` > >> method of novaclient's server object[4]. This method is missed in the > latest > >> novaclient (see [2]). > >>It means that this command is broken now. > > >> So here we have 2 global issues: > >> - openstackclient has a broken command (or I missed something?) > >> - there is no easy way to associate a floating ip with a vm using CLI or > >> via python. > > > I mentioned the related issue back in January: > > > > http://lists.openstack.org/pipermail/openstack-dev/2018- > January/126741.html > > > > Adding a floating IP to an instance is possible using OSC CLI, it's > > essentially something like: > > > > a) get the server id (openstack server show/list) > > b) get the port id using the server id (openstack port list --device-id > > $server_id) > > c) assign the floating IP to the port (openstack floating ip set --port > > $port_id) > > > We keep removing Python API bindings from client libraries that are > still in use for old clouds that are still in much wider use than we > would like. Why do we not give a rats ass about our users? > Especially when some deployers have multiple clouds lying about, > requiring them to maintain multiple venvs of CLIs is just stupid to be > able to work on their clouds and migrations to the cool new stuff. > > OSC is not done because I have about 3 hours a week left to work on > it. Continued shit like this isn't helping me want to keep going. > Maybe my brain is just snow-fried. And for the love of all the snow > in Dublin, please, NOBODY USE THE SDK IN A SERVICE. Keeping service > assumptions out of client-side stuff is the biggest reason OSC NEEDS > to get changed over to the SDK, like, 2 years ago. Then I'll not give > a rats ass about the legacy python client libs. > > > dt > > -- > > Dean Troyer > dtro...@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 > -- Best regards, Andrey Kurilin. __ 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][neutron][openstackclient] The way to assign floating IPs to VM
Hi stackers! A year ago, Nova team decided to deprecate the addFixedIP, removeFixedIP, addFloatingIP, removeFloatingIP server action APIs and it was done[1]. It looks like not all the consumers paid attention to this change so after novaclient 10.0.0 release (which includes removal of these interfaces[2]) got in u-c file [3] I found broken code in my repo :( I tried to find an alternative way to associate a floating ip with an instance and I faced several new issues: - openstackclient * command `openstack server add floating ip` calls `add_floating_ip` method of novaclient's server object[4]. This method is missed in the latest novaclient (see [2]). It means that this command is broken now. - neutronclient * CLI is deprecated * the python binding accepts floating ip id (need to list all floating IPs to find the id) and port id to attach floating to (where should I take port id?!). So here we have 2 global issues: - openstackclient has a broken command (or I missed something?) - there is no easy way to associate a floating ip with a vm using CLI or via python. [1] https://github.com/openstack/python-novaclient/blob/master/releasenotes/notes/microversion-v2_44-d60c8834e436ad3d.yaml [2] https://github.com/openstack/python-novaclient/blob/master/releasenotes/notes/remove-virt-interfaces-add-rm-fixed-floating-398c905d9c91cca8.yaml [3] https://github.com/openstack/requirements/commit/c126685c2007c818e65c53cc9c32885fae16fd34 [4] https://github.com/openstack/python-openstackclient/blob/b10941ddf6f7f6894b7d87f25c173f227b111e4e/openstackclient/compute/v2/server.py#L266-L267 -- Best regards, Andrey Kurilin. __ 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] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP
Imo, it creates more problems than profits. If someone wants to change the code and run tests -> use git repositories. Prepared python package is not about this. 2018-02-19 17:57 GMT+02:00 Doug Hellmann <d...@doughellmann.com>: > IIRC we started doing that so that consumers building their own packages > can run the tests for the packages easily. I don't know how many people > are doing that, and apparently at least some downstream consumers aren't > packaging everything anyway so they couldn't run those tests. > > Excerpts from Andrey Kurilin's message of 2018-02-19 17:39:11 +0200: > > Can someone explain me the reason for including "tests" module into > > packages? > > > > 2018-02-19 17:00 GMT+02:00 Michael Bayer <mba...@redhat.com>: > > > > > Hi list - > > > > > > Apparently Cinder was misled by my deprecations within the > > > oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and > > > in https://review.openstack.org/#/c/522290/ the assumption was made > > > that these should be imported from oslo_db.tests.sqlalchemy.This > > > is an immense mistake on my part that I did not expect people to go > > > looking for the same names elsewhere in private packages and now we > > > have a serious downstream issue as these modules are not packaged, as > > > well as the possibility that the oslo_db.tests. package is now locked > > > in time and I have to add deprecations there also. > > > > > > If anyone knows of projects (or feels like helping me search) that are > > > importing *anything* from oslo_db.tests these must be reverted ASAP. > > > > > > > __ > > > 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 > -- Best regards, Andrey Kurilin. __ 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] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP
As for downstream you can do whatever you want, but it looks like this issue should be solved in upstream. I mean if "tests" directory is located at the top level of the repo, no one will use it. Also, setuptools supports `exclude` option which should solve the issue as well. 2018-02-19 17:41 GMT+02:00 Michael Bayer <mba...@redhat.com>: > On Mon, Feb 19, 2018 at 10:39 AM, Andrey Kurilin <andr.kuri...@gmail.com> > wrote: > > Can someone explain me the reason for including "tests" module into > > packages? > > the "tests" module should not be inside packages. Downstream we have > CI running Cinder's test suite against packaged dependencies, which > fails because we don't package oslo_db.tests. > > > > > > > > 2018-02-19 17:00 GMT+02:00 Michael Bayer <mba...@redhat.com>: > >> > >> Hi list - > >> > >> Apparently Cinder was misled by my deprecations within the > >> oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and > >> in https://review.openstack.org/#/c/522290/ the assumption was made > >> that these should be imported from oslo_db.tests.sqlalchemy.This > >> is an immense mistake on my part that I did not expect people to go > >> looking for the same names elsewhere in private packages and now we > >> have a serious downstream issue as these modules are not packaged, as > >> well as the possibility that the oslo_db.tests. package is now locked > >> in time and I have to add deprecations there also. > >> > >> If anyone knows of projects (or feels like helping me search) that are > >> importing *anything* from oslo_db.tests these must be reverted ASAP. > >> > >> > __ > >> 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 > > > > > > > > > > -- > > Best regards, > > Andrey Kurilin. > > > > > __ > > 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 > -- Best regards, Andrey Kurilin. __ 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] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP
Can someone explain me the reason for including "tests" module into packages? 2018-02-19 17:00 GMT+02:00 Michael Bayer <mba...@redhat.com>: > Hi list - > > Apparently Cinder was misled by my deprecations within the > oslo_db.sqlalchemy.test_base package of DbFixture and DbTestCase, and > in https://review.openstack.org/#/c/522290/ the assumption was made > that these should be imported from oslo_db.tests.sqlalchemy.This > is an immense mistake on my part that I did not expect people to go > looking for the same names elsewhere in private packages and now we > have a serious downstream issue as these modules are not packaged, as > well as the possibility that the oslo_db.tests. package is now locked > in time and I have to add deprecations there also. > > If anyone knows of projects (or feels like helping me search) that are > importing *anything* from oslo_db.tests these must be reverted ASAP. > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] Adding Takashi Natsume to python-novaclient core
\o/ Welcome to the team! 2018-02-15 19:18 GMT+02:00 Matt Riedemann <mriede...@gmail.com>: > On 2/9/2018 9:01 AM, Matt Riedemann wrote: > >> I'd like to add Takashi to the python-novaclient core team. >> >> python-novaclient doesn't get a ton of activity or review, but Takashi >> has been a solid reviewer and contributor to that project for quite awhile >> now: >> >> http://stackalytics.com/report/contribution/python-novaclient/180 >> >> He's always fast to get new changes up for microversion support and help >> review others that are there to keep moving changes forward. >> >> So unless there are objections, I'll plan on adding Takashi to the >> python-novaclient-core group next week. >> > > I've added Takashi to python-novaclient-core: > > https://review.openstack.org/#/admin/groups/572,members > > Thanks everyone. > > > -- > > Thanks, > > Matt > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] Adding Takashi Natsume to python-novaclient core
+1 Takashi, thanks for your contribution! 2018-02-11 4:48 GMT+02:00 Alex Xu <sou...@gmail.com>: > +1 > > 2018-02-09 23:01 GMT+08:00 Matt Riedemann <mriede...@gmail.com>: > >> I'd like to add Takashi to the python-novaclient core team. >> >> python-novaclient doesn't get a ton of activity or review, but Takashi >> has been a solid reviewer and contributor to that project for quite awhile >> now: >> >> http://stackalytics.com/report/contribution/python-novaclient/180 >> >> He's always fast to get new changes up for microversion support and help >> review others that are there to keep moving changes forward. >> >> So unless there are objections, I'll plan on adding Takashi to the >> python-novaclient-core group next week. >> >> -- >> >> Thanks, >> >> Matt >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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 > > -- Best regards, Andrey Kurilin. __ 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] [heat][rally] What should we do with legacy-rally-dsvm-fakevirt-heat
Hi Rico 2018-02-08 11:38 GMT+02:00 Rico Lin <rico.lin.gua...@gmail.com>: > Thx Andrey, looking forward to new rally job > > At meanwhile, seems current job is broken [1] > Based on the error, the fix requires +2;-2 change to https://github.com/openstack/heat/blob/master/rally-scenarios/plugins/stack_output.py . I can propose a patch with a fix and we can leave legacy-rally job at experimental queue. Or we can return to this after sometime. I'm ok about both cases. > and we're expecting for a new job to replace. > We will remove the old legacy one (see patch [2]) for now if that won't > break rally (in any way). > I'm changing only config for heat (under zuul.d/projects.yaml), won't > touch `legacy-rally-dsvm-fakevirt-heat` itself (I guess that is up to > rally team to remove it later) > > [1] http://logs.openstack.org/29/531929/3/experimental/ > legacy-rally-dsvm-fakevirt-heat/cd797f4/job-output.txt. > gz#_2018-02-08_05_02_37_258609 > [2] https://review.openstack.org/542111 > > 2018-02-08 3:39 GMT+08:00 Andrey Kurilin <andr.kuri...@gmail.com>: > >> Hi Rico and stackers, >> >> Thanks for raising this topic. >> >> Short answer: please leave it as is for now. Rally team will work on >> ZuulV3 jobs soon. >> >> Detailed: We are planning to make some big changes in our architecture >> which includes splitting the main repo into a separate repository for a >> framework and a separate repository for all OpenStack plugins. >> To minimize work across all projects which have Rally job, we decided to >> pause working on ZuulV3 until the split will be finished. >> As for estimates, I'm planning to make the final release before splitting >> today or tomorrow. As soon as new release will be ready, we will start >> working on splitting and CI as well. >> >> Thanks for the patient and for using Rally! >> >> 2018-02-07 10:13 GMT+02:00 Rico Lin <rico.lin.gua...@gmail.com>: >> >>> Hi heat and rally team >>> >>> Right now, in heat's zuul jobs. We still got one legacy job to change >>> `legacy-rally-dsvm-fakevirt-heat` [1] which I already put a patch out >>> here [2], but after discussion with infra team, it seems best if we can >>> define this in rally, and reference it in heat. >>> So my question to rally team for all these will be, do we still need >>> this job? and how you guys think about if we put that into rally? >>> >>> [1] https://github.com/openstack-infra/project-config/blob/m >>> aster/zuul.d/projects.yaml#L6979 >>> [2] https://review.openstack.org/#/c/509141 >>> -- >>> May The Force of OpenStack Be With You, >>> >>> *Rico Lin*irc: ricolin >>> >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.op >>> enstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> Best regards, >> Andrey Kurilin. >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > May The Force of OpenStack Be With You, > > *Rico Lin*irc: ricolin > > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] [heat][rally] What should we do with legacy-rally-dsvm-fakevirt-heat
Hi Rico and stackers, Thanks for raising this topic. Short answer: please leave it as is for now. Rally team will work on ZuulV3 jobs soon. Detailed: We are planning to make some big changes in our architecture which includes splitting the main repo into a separate repository for a framework and a separate repository for all OpenStack plugins. To minimize work across all projects which have Rally job, we decided to pause working on ZuulV3 until the split will be finished. As for estimates, I'm planning to make the final release before splitting today or tomorrow. As soon as new release will be ready, we will start working on splitting and CI as well. Thanks for the patient and for using Rally! 2018-02-07 10:13 GMT+02:00 Rico Lin <rico.lin.gua...@gmail.com>: > Hi heat and rally team > > Right now, in heat's zuul jobs. We still got one legacy job to change > `legacy-rally-dsvm-fakevirt-heat` [1] which I already put a patch out > here [2], but after discussion with infra team, it seems best if we can > define this in rally, and reference it in heat. > So my question to rally team for all these will be, do we still need this > job? and how you guys think about if we put that into rally? > > [1] https://github.com/openstack-infra/project-config/blob/master/zuul.d/ > projects.yaml#L6979 > [2] https://review.openstack.org/#/c/509141 > -- > May The Force of OpenStack Be With You, > > *Rico Lin*irc: ricolin > > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] [rally]404 on docker rallyforge/rally
hi folks! As Chen already mentioned, we had an issue with rallyforge account. I'm working with docker support team to return the repository. The result should appear soon. Sorry for inconvenience. 2017-12-05 6:28 GMT+02:00 Swapnil Kulkarni <cools...@gmail.com>: > On Tue, Dec 5, 2017 at 5:35 AM, <chen.haibi...@zte.com.cn> wrote: > > Hi, sorry for the inconvenience. > > > > docker team removed the rallyforge/rally repo. PTL has contacted them > some > > days ago, but did not get the answer. > > > > Let us wait some days, if still not answer, we will create another repo > > (xrally/rally) for this. > > > > > > Best regards > > > > chen > > > > > > > > > > > > Original Mail > > Sender: <matthieu.simo...@inria.fr>; > > To: <openstack-dev@lists.openstack.org>; > > Date: 2017/12/04 23:18 > > Subject: Re: [openstack-dev] [rally]404 on docker rallyforge/rally > > > > > > - Mail original - > >> De: "Swapnil Kulkarni" <cools...@gmail.com> > >> À: "OpenStack Development Mailing List (not for usage questions)" > >> <openstack-dev@lists.openstack.org> > >> Envoyé: Lundi 4 Décembre 2017 12:57:36 > >> Objet: Re: [openstack-dev] [rally]404 on docker rallyforge/rally > >> > >> On Mon, Dec 4, 2017 at 4:13 PM, Matthieu Simonin > >> <matthieu.simo...@inria.fr> wrote: > >> > Hi, > >> > > >> > Monday morning and it seems that docker images for rally aren't > >> > reachable > >> > anymore. > >> > > >> > https://hub.docker.com/r/rallyforge/rally/ > >> > > >> > Did I miss something ? Is the doc up-to-date[1] ? > >> > > >> > [1]: > >> > > >> > http://rally.readthedocs.io/en/0.10.0/install_and_upgrade/ > install.html#rally-docker > >> > > >> > Matt > >> > > >> > > >> > > __ > >> > 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 > >> > >> > >> I think you need to refer to [1] for updated docs and [2] should be > >> able to help you with rally-docker information which might be useful > >> for you. > > > > Thanks Swapnil, but the namespace rallyforge[1] is now empty > > (or all images are private) on docker hub. > > > > I have no problem building images on my own, but I just wanted to make > > sure this is now the only way I can use the rally images. > > > > If so the doc will need to be updated to remove any reference to > > rallyforge/rally. > > > > > > [1] https://hub.docker.com/r/rallyforge/ > > > > Best, > > > > Matthieu > > > >> > >> [1] https://docs.openstack.org/rally/latest/ > >> [2] > >> > >> https://docs.openstack.org/rally/latest/install_and_ > upgrade/install.html#rally-docker > >> > >> > __ > >> 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 > > > > I was not sure about the defunct rally repo on docker hub. My bad. I > think yeah, till the time the new repo is operational building images > and using them would be a better idea. > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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][charms][fuel][Packaging-Deb] Remove old numeric branches
Hi Tony and folks, I missed the original thread (had read just [charms][fuel][Packaging-Deb] tags), so disappeared branch surprised me a lot. stable/0.9 branch of Rally project was created for supporting the previous major release (last week, 0.9 was the current major release). We released 0.10.0 just several days ago and want to continue supporting 0.9 for awhile. Since this is critical for several our customers, it would be nice if we can push stable/0.9 back (I have a local copy in the final state [0]). Also, I'll be happy, if we can remove 0.9-eol tag from the git.o.o, gihtub and pypi. PS: it would be nice if tags for all affected projects is added next time. or, even better, if all PTLs of affected projects is added to CC [0] - https://github.com/andreykurilin/rally/tree/stable/0.9 2017-10-25 6:38 GMT+03:00 Tony Breeds <t...@bakeyournoodle.com>: > On Wed, Sep 20, 2017 at 01:52:11PM -0400, Tony Breeds wrote: > > Hello all, > > Now we have cleaned up some of the older series based branches I've > > taken a look at some of the numeric based branches. > > > > The projects in $subject are particularly impacted. I've made my best > > guess at which branches are current, but I'd really appreciate guidance > > on the life span of these branches. > > > > As before as the ultimate consumer of the data is infra I've presented > > this in a form that's easy for them to consume: > > > > Ideally I'd like to move on this this week but that isn't enough > > consultation. So I'll pass the list to infra Monday 2nd October > > The branches in http://lists.openstack.org/pipermail/openstack-dev/2017- > September/122381.html > have been removed now. > > There was small issues with the openstack/deb-gnocchi and > openstack/deb-python-gnocchiclient in that the .gitreview file pointed > at the wrong repo (upstream in this case). These were corrected > manually > > Also: > - openstack/deb-python-django-pyscss > - openstack/charm-plumgrid-director > - openstack/charm-plumgrid-edge > - openstack/charm-plumgrid-gateway > > All seemed to be missing .gitreview files to the remote needed to be > added manually. > > Yours Tony. > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] review.openstack.org downtime and Gerrit upgrade
hi Clark, Do you have any plans to update to 2.14 release which has a new polymer based user interface? 2017-08-03 1:57 GMT+03:00 Clark Boylan <cboy...@sapwetik.org>: > Hello, > > The Infra team is planning to upgrade review.openstack.org from Gerrit > 2.11 to Gerrit 2.13 on September 18, 2017. This downtime will begin at > 1500UTC and is expected to take many hours as we have to perform an > offline update of Gerrit's secondary indexes. The outage should be > complete by 2359UTC. > > This upgrade is a relatively minor one for users. You'll find that > mobile use of Gerrit is slightly better (though still not great). The > bug that forces us to reapply Approval votes rather than just rechecking > has also been addressed. If you'd like to test out Gerrit 2.13 you can > do so at https://review-dev.openstack.org. > > The date we have chosen is the Monday after the PTG. The > expectation/hope is that many people will still be traveling or > otherwise recovering from the PTG so demand for Gerrit will be low. By > doing it on Monday we also hope that there will be load on the service > the following day which should help shake out any issues quickly (in the > past we've done it on weekends then had to wait a couple days before > problems are noticed). > > If you have any concerns or feedback please let the Infra team know. > > Thank you, > 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 > -- Best regards, Andrey Kurilin. __ 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] [glance][rally] Disabling Glance Testing in Rally gates
Hi Flavio, 2017-07-13 11:16 GMT+03:00 Flavio Percoco <fla...@redhat.com>: > On 13/07/17 00:56 -0700, Boris Pavlovic wrote: > >> Hi stackers, >> >> >> Unfortunately what was discussed in other thread (situation in glance is >> critical) happened. >> Glance stopped working and Rally team is forced to disable checking of it >> in Rally gates. >> >> P.S. Seems like this patch is casing the problems: >> https://github.com/openstack-dev/devstack/commit/1fa65363578 >> 1cd975a1031e212b35b6c38196ba4 >> > > Hey Boris, > > Has this been brought up to the Glance team? Or is this email meant to do > that? > > Yes http://eavesdrop.openstack.org/irclogs/%23openstack-glance/%23openstack-glance.2017-07-11.log.html#t2017-07-11T07:44:13 http://eavesdrop.openstack.org/irclogs/%23openstack-glance/%23openstack-glance.2017-07-11.log.html#t2017-07-11T22:12:47 > FWIW, the switch to uwsgi is a community goal and not so much a Glance > thing. > Would you mind elaborating on what exactly is failing and how the glance > team > can help? > > I understand that switching to uwsgi is a community goal, but we didn't have any problems with Glance for years until now. As from IRC logs: > HTTPBadGateway: 502 Bad Gateway: Bad Gateway: The proxy server received an invalid: response from an upstream server.: Apache/2.4.18 (Ubuntu) Server at 158.69.73.26 Port 80 (HTTP 502) Trace: http://paste.openstack.org/show/615234/ Flavio > > -- > @flaper87 > Flavio Percoco > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] [trove][all][tc] A proposal to rearchitect Trove
2017-06-22 18:59 GMT+03:00 Fox, Kevin M <kevin@pnnl.gov>: > My $0.02. > > That view of dependencies is why Kubernetes development is outpacing > OpenStacks and some users are leaving IMO. Not trying to be mean here but > trying to shine some light on this issue. > > Kubernetes at its core has essentially something kind of equivalent to > keystone (k8s rbac), nova (container mgmt), cinder (pv/pvc/storageclasses), > heat with convergence (deployments/daemonsets/etc), barbican (secrets), > designate (kube-dns), and octavia (kube-proxy,svc,ingress) in one unit. Ops > dont have to work hard to get all of it, users can assume its all there, > and devs don't have many silo's to cross to implement features that touch > multiple pieces. > > This core functionality being combined has allowed them to land features > that are really important to users but has proven difficult for OpenStack > to do because of the silo's. OpenStack's general pattern has been, stand up > a new service for new feature, then no one wants to depend on it so its > ignored and each silo reimplements a lesser version of it themselves. > > Totally agree The OpenStack commons then continues to suffer. > > We need to stop this destructive cycle. > > OpenStack needs to figure out how to increase its commons. Both internally > and externally. etcd as a common service was a step in the right direction. > > I think k8s needs to be another common service all the others can rely on. > That could greatly simplify the rest of the OpenStack projects as a lot of > its functionality no longer has to be implemented in each project. > > We also need a way to break down the silo walls and allow more cross > project collaboration for features. I fear the new push for letting > projects run standalone will make this worse, not better, further > fracturing OpenStack. > > Thanks, > Kevin > > From: Thierry Carrez [thie...@openstack.org] > Sent: Thursday, June 22, 2017 12:58 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect > Trove > > Fox, Kevin M wrote: > > [...] > > If you build a Tessmaster clone just to do mariadb, then you share > nothing with the other communities and have to reinvent the wheel, yet > again. Operators load increases because the tool doesn't function like > other tools. > > > > If you rely on a container orchestration engine that's already cross > cloud that can be easily deployed by user or cloud operator, and fill in > the gaps with what Trove wants to support, easy management of db's, you get > to reuse a lot of the commons and the users slight increase in investment > in dealing with the bit of extra plumbing in there allows other things to > also be easily added to their cluster. Its very rare that a user would need > to deploy/manage only a database. The net load on the operator decreases, > not increases. > > I think the user-side tool could totally deploy on Kubernetes clusters > -- if that was the only possible target that would make it a Kubernetes > tool more than an open infrastructure tool, but that's definitely a > possibility. I'm not sure work is needed there though, there are already > tools (or charts) doing that ? > > For a server-side approach where you want to provide a DB-provisioning > API, I fear that making the functionality depend on K8s would make > TroveV2/Hoard would not only depend on Heat and Nova, but also depend on > something that would deploy a Kubernetes cluster (Magnum?), which would > likely hurt its adoption (and reusability in simpler setups). Since > databases would just work perfectly well in VMs, it feels like a > gratuitous dependency addition ? > > We generally need to be very careful about creating dependencies between > OpenStack projects. On one side there are base services (like Keystone) > that we said it was alright to depend on, but depending on anything else > is likely to reduce adoption. Magnum adoption suffers from its > dependency on Heat. If Heat starts depending on Zaqar, we make the > problem worse. I understand it's a hard trade-off: you want to reuse > functionality rather than reinvent it in every project... we just need > to recognize the cost of doing that. > > -- > 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 > > _______
Re: [openstack-dev] [all][ptls][tc] help needed filling out project-navigator data
Hi folks! Does it possible to store history of the project without alignment to OpenStack releases? 2017-04-19 17:54 GMT+03:00 Jimmy McArthur <ji...@openstack.org>: > Ideally, as far back as your project goes. That way we will have a > complete API history, per release, on the project navigator. This also > helps us determine the project age. > > Thanks! > Jimmy > > Telles Nobrega <tenob...@redhat.com> > April 19, 2017 at 9:48 AM > Hi Monty, > > quick question, how far into past releases should we go? > > Thanks, > > -- > > TELLES NOBREGA > > SOFTWARE ENGINEER > > Red Hat I <https://www.redhat.com/> > > tenob...@redhat.com > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > __ > 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 > Monty Taylor <mord...@inaugust.com> > April 18, 2017 at 3:03 PM > Hey everybody! > > The Foundation is rolling out a new version of the Project Navigator. One > of the things it contains is a section that shows API versions available > for each project for each release. They asked the TC's help in providing > that data, so we spun up a new repository: > > http://git.openstack.org/cgit/openstack/project-navigator-data > > that the Project Navigator will consume. > > We need your help! > > The repo contains a file for each project for each release with > CURRENT/SUPPORTED/DEPRECATED major versions and also microversion ranges if > they exist. The data is pretty much exactly what everyone already produces > in their version discovery documents - although it's normalized into the > format described by the API-WG: > > > https://specs.openstack.org/openstack/api-wg/guidelines/ > microversion_specification.html#version-discovery > > What would be really helpful is if someone from each project could go make > a patch to the repo adding the historical (and currently) info for your > project. We'll come up with a process for maintaining it over time - but > for now just crowdsourcing the data seems like the best way. > > The README file explains the format, and there is data from a few of the > projects for Newton. > > It would be great to include an entry for every release - which for many > projects will just be the same content copied a bunch of times back to the > first release the project was part of OpenStack. > > This is only needed for service projects (something that registers in the > keystone catalog) and is only needed for 'main' APIs (like, it is not > needed, for now, to put in things like Placement) > > If y'all could help - it would be super great! > > Thanks! > Monty > > __ > > 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 > > -- Best regards, Andrey Kurilin. __ 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] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)
On Thu, Feb 16, 2017 at 1:57 PM, Radomir Dopieralski <openst...@sheep.art.pl > wrote: > I think that you have to remember that OpenStack doesn't only work with > officially approved OpenStack services, but with any services that have a > conforming API. > Yes, I forgot about it. But it changes nothing. Custom implementation of particular service should cover the same API as an official one. For me, as for user, it doesn't metter if there is Keystone or MyAwesomeKeystone, I want just an service which implements Keystone functionality. > OpenStack itself provides implementations of those services, and you are > right that it's unlikely that there will be two competing implementations > for the same service type officially endorsed by OpenStack. But you are > ignoring 3rd-party services that are being used, and also the possibility > that the services will change in the future. Since it doesn't really cost > us to keep this flexibility, I think it's reasonable to keep doing it. > > On Thu, Feb 16, 2017 at 11:55 AM, Andrey Kurilin <akuri...@mirantis.com> > wrote: > >> Hi everyone! >> >> When I started contribution to OpenStack long time ago, I asked about the >> reason of having two entities - service type and name; at that time I got >> an answer that service name is a name of the project that implements >> particular service type, so it is possible to have several projects which >> implement one service type. That answer satisfied me. >> >> The reality of OpenStack is that there is no and there will not be >> several implementations of one "service type". Even when we had nova-net >> and neutron, only the neutron registered his service in the catalog. >> >> An example of Octavia shows that everybody was ok about having service >> name equal with type before inconsistency was found. That is why I want to >> ask again: Do we need two separate entities and if yes - why? Maybe service >> name and description fields should be enough? >> >> On Wed, Feb 15, 2017 at 3:08 AM, Qiming Teng <teng...@linux.vnet.ibm.com> >> wrote: >> >>> When reviewing a recent patch that adds openstacksdk support to octavia, >>> I found that octavia is using 'octavia' as its service name instead of >>> 'loadbalancing' or 'loadbalancingv2' or something similar. >>> >>> The overall suggestion is to use a word/phrase that indicates what a >>> service do instead of the name of the project providing that service. >>> >>> Below is the list of the service types currently supported by >>> openstacksdk: >>> >>> 'alarming',# aodh >>> 'baremetal', # ironic >>> 'clustering', # senlin >>> 'compute', # nova >>> 'database',# trove >>> 'identity',# keystone >>> 'image', # glance >>> 'key-manager', # barbican >>> 'messaging', # zaqar >>> 'metering',# ceilometer >>> 'network', # neutron >>> 'object-store', # swift >>> 'octavia',# <--- this is an exception >>> 'orchestration', # heat >>> 'volume', # cinder >>> 'workflowv2', # mistral >>> >>> While I believe this has been discussed about a year ago, I'm not sure >>> if there are things we missed so I'm brining this issue to a broader >>> audience for discussion. >>> >>> Reference: >>> >>> [1] Patch to python-openstacksdk: >>> https://review.openstack.org/#/c/428414 >>> [2] Octavia service naming: >>> http://git.openstack.org/cgit/openstack/octavia/tree/devstac >>> k/plugin.sh#n52 >>> >>> Regards, >>> Qiming >>> >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.op >>> enstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >> -- >> Best regards, >> Andrey Kurilin. >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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 > > -- Best regards, Andrey Kurilin. __ 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] [all] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)
Hi everyone! When I started contribution to OpenStack long time ago, I asked about the reason of having two entities - service type and name; at that time I got an answer that service name is a name of the project that implements particular service type, so it is possible to have several projects which implement one service type. That answer satisfied me. The reality of OpenStack is that there is no and there will not be several implementations of one "service type". Even when we had nova-net and neutron, only the neutron registered his service in the catalog. An example of Octavia shows that everybody was ok about having service name equal with type before inconsistency was found. That is why I want to ask again: Do we need two separate entities and if yes - why? Maybe service name and description fields should be enough? On Wed, Feb 15, 2017 at 3:08 AM, Qiming Teng <teng...@linux.vnet.ibm.com> wrote: > When reviewing a recent patch that adds openstacksdk support to octavia, > I found that octavia is using 'octavia' as its service name instead of > 'loadbalancing' or 'loadbalancingv2' or something similar. > > The overall suggestion is to use a word/phrase that indicates what a > service do instead of the name of the project providing that service. > > Below is the list of the service types currently supported by > openstacksdk: > > 'alarming',# aodh > 'baremetal', # ironic > 'clustering', # senlin > 'compute', # nova > 'database',# trove > 'identity',# keystone > 'image', # glance > 'key-manager', # barbican > 'messaging', # zaqar > 'metering',# ceilometer > 'network', # neutron > 'object-store', # swift > 'octavia',# <--- this is an exception > 'orchestration', # heat > 'volume', # cinder > 'workflowv2', # mistral > > While I believe this has been discussed about a year ago, I'm not sure > if there are things we missed so I'm brining this issue to a broader > audience for discussion. > > Reference: > > [1] Patch to python-openstacksdk: > https://review.openstack.org/#/c/428414 > [2] Octavia service naming: > http://git.openstack.org/cgit/openstack/octavia/tree/ > devstack/plugin.sh#n52 > > Regards, > Qiming > > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] [governance][tc][rally] Rally (Re: [rally][release] How rally release version)
On Mon, Feb 13, 2017 at 4:49 PM, Davanum Srinivas <dava...@gmail.com> wrote: > Andrey, > > It's a question, not a proposal. > Sorry, but your message doesn't sound like a question. It sounds like a polite proposal. > If you don't do use releases repo, then rally information will be stale > here: > https://releases.openstack.org/ > > Here's why we have a release team and things we do: > https://governance.openstack.org/tc/reference/projects/relea > se-management.html > https://specs.openstack.org/openstack-infra/infra-specs/spec > s/centralize-release-tagging.html > http://docs.openstack.org/project-team-guide/release-management.html > > Since Rally is following the independent model, it has a whole lot of > leeway: > http://docs.openstack.org/project-team-guide/release-managem > ent.html#independent-release-model > > However the absolute minimum requirement is that the releases repo > should be kept in sync. If that is too cumbersome, i don't know... > > Please re-read your first mail in the thread. It is not about synchronizing release notes at all. You are asking about throwing Rally project out from Big Tent due to ourdated info posted at https://releases.openstack.org. Seriusly? To finish this topic: - As a Rally PTL, I do not want to drop the project out of Big Tent. At least for now. Who knows what will happen when you will extend bureaucracy someday... - I'll update info at openstack/releases repo soon and will try to do it in the right time while releasing new versions. - Rally follows the rules described by: * http://docs.openstack.org/project-team-guide/release-managem ent.html#independent-release-model * http://docs.openstack.org/project-team-guide/release-management.html#release-process-for-other-projects > OpenStack projects following a cycle-independent model can ... push signed tags by themselves. - There are no reasons to continue discussion dropping Rally. I can start a ton of topics like "Drop Nova" with similar "real" reasons. - I'm not against the work done by OpenStack Release team. I had a good experience with that while working in not-Rally projects. > Thanks, > Dims > > > > On Mon, Feb 13, 2017 at 9:15 AM, Andrey Kurilin <akuri...@mirantis.com> > wrote: > > Hi Dims! > > > > I do not want to say except question "why you are proposing to do that?". > > > > I tried to find any rules about releasing at > > https://governance.openstack.org, but I could not. > > Please point me what rule I broke. > > > > On Mon, Feb 13, 2017 at 3:57 PM, Davanum Srinivas <dava...@gmail.com> > wrote: > >> > >> Andrey, Rally team, > >> > >> Do you want Rally to be dropped from Governance and Releases repository? > >> > >> Thanks, > >> Dims > >> > >> On Mon, Feb 13, 2017 at 8:17 AM, Jeffrey Zhang <zhang.lei@gmail.com > > > >> wrote: > >> > @Andrey, thanks for the explanation. > >> > > >> > The issue is: how can i know which tag works with certain OpenStack > >> > branch? > >> > For example, which tag > >> > works with OpenStack Ocata release? There is no place recording this. > >> > > >> > I also found there are some other project do not use > "project/releases" > >> > project. May they are using > >> > the same solution as rally. > >> > > >> > On Mon, Feb 13, 2017 at 6:14 PM, Andrey Kurilin < > akuri...@mirantis.com> > >> > wrote: > >> >> > >> >> Hi Jeffrey, > >> >> > >> >> Rally team do not use "releases" repo at all, that is why information > >> >> at > >> >> [2] is outdated. > >> >> Our release workflow is making a proper tag and pushing it via > Gerrit. > >> >> I > >> >> find it more convenient. > >> >> > >> >> > >> >> > >> >> On Mon, Feb 13, 2017 at 9:13 AM, Jeffrey Zhang > >> >> <zhang.lei@gmail.com> > >> >> wrote: > >> >>> > >> >>> Hey guys, > >> >>> > >> >>> I found rally already releases its 0.8.1 tag from[0][1]. But > >> >>> I found nothing in openstack/releases project[2]. How rally > >> >>> create tag? > >> >>> > >> >>> [0] http://tarballs.openstack.org/rally/ > >> >>> [1] https://github.com/openstack/rally/releases > >> >>> [2] > >> >>> > >> >&g
Re: [openstack-dev] [governance][tc][rally] Rally (Re: [rally][release] How rally release version)
Hi Dims! I do not want to say except question "why you are proposing to do that?". I tried to find any rules about releasing at https://governance.openstack.org, but I could not. Please point me what rule I broke. On Mon, Feb 13, 2017 at 3:57 PM, Davanum Srinivas <dava...@gmail.com> wrote: > Andrey, Rally team, > > Do you want Rally to be dropped from Governance and Releases repository? > > Thanks, > Dims > > On Mon, Feb 13, 2017 at 8:17 AM, Jeffrey Zhang <zhang.lei@gmail.com> > wrote: > > @Andrey, thanks for the explanation. > > > > The issue is: how can i know which tag works with certain OpenStack > branch? > > For example, which tag > > works with OpenStack Ocata release? There is no place recording this. > > > > I also found there are some other project do not use "project/releases" > > project. May they are using > > the same solution as rally. > > > > On Mon, Feb 13, 2017 at 6:14 PM, Andrey Kurilin <akuri...@mirantis.com> > > wrote: > >> > >> Hi Jeffrey, > >> > >> Rally team do not use "releases" repo at all, that is why information at > >> [2] is outdated. > >> Our release workflow is making a proper tag and pushing it via Gerrit. I > >> find it more convenient. > >> > >> > >> > >> On Mon, Feb 13, 2017 at 9:13 AM, Jeffrey Zhang <zhang.lei@gmail.com > > > >> wrote: > >>> > >>> Hey guys, > >>> > >>> I found rally already releases its 0.8.1 tag from[0][1]. But > >>> I found nothing in openstack/releases project[2]. How rally > >>> create tag? > >>> > >>> [0] http://tarballs.openstack.org/rally/ > >>> [1] https://github.com/openstack/rally/releases > >>> [2] > >>> https://github.com/openstack/releases/blob/master/ > deliverables/_independent/rally.yaml#L45 > >>> > >>> -- > >>> Regards, > >>> Jeffrey Zhang > >>> Blog: http://xcodest.me > >>> > >>> > >>> > __ > >>> 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 > >>> > >> > >> > >> > >> -- > >> Best regards, > >> Andrey Kurilin. > >> > >> > __ > >> 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, > > Jeffrey Zhang > > Blog: http://xcodest.me > > > > > __ > > 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 > > > > > > -- > Davanum Srinivas :: https://twitter.com/dims > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] [rally][release] How rally release version
On Mon, Feb 13, 2017 at 3:17 PM, Jeffrey Zhang <zhang.lei@gmail.com> wrote: > @Andrey, thanks for the explanation. > > The issue is: how can i know which tag works with certain OpenStack > branch? For example, which tag > works with OpenStack Ocata release? There is no place recording this. > > Rally project doesn't have alignment to any OpenStack release, since we do not depend much on them. Latest release of Rally should work for all OpenStack releases. > I also found there are some other project do not use "project/releases" > project. May they are using > the same solution as rally. > > On Mon, Feb 13, 2017 at 6:14 PM, Andrey Kurilin <akuri...@mirantis.com> > wrote: > >> Hi Jeffrey, >> >> Rally team do not use "releases" repo at all, that is why information at >> [2] is outdated. >> Our release workflow is making a proper tag and pushing it via Gerrit. I >> find it more convenient. >> >> >> >> On Mon, Feb 13, 2017 at 9:13 AM, Jeffrey Zhang <zhang.lei@gmail.com> >> wrote: >> >>> Hey guys, >>> >>> I found rally already releases its 0.8.1 tag from[0][1]. But >>> I found nothing in openstack/releases project[2]. How rally >>> create tag? >>> >>> [0] http://tarballs.openstack.org/rally/ >>> [1] https://github.com/openstack/rally/releases >>> [2] https://github.com/openstack/releases/blob/master/delive >>> rables/_independent/rally.yaml#L45 >>> >>> -- >>> Regards, >>> Jeffrey Zhang >>> Blog: http://xcodest.me >>> >>> ________ >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.op >>> enstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> Best regards, >> Andrey Kurilin. >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Regards, > Jeffrey Zhang > Blog: http://xcodest.me > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] [rally][release] How rally release version
Hi Jeffrey, Rally team do not use "releases" repo at all, that is why information at [2] is outdated. Our release workflow is making a proper tag and pushing it via Gerrit. I find it more convenient. On Mon, Feb 13, 2017 at 9:13 AM, Jeffrey Zhang <zhang.lei@gmail.com> wrote: > Hey guys, > > I found rally already releases its 0.8.1 tag from[0][1]. But > I found nothing in openstack/releases project[2]. How rally > create tag? > > [0] http://tarballs.openstack.org/rally/ > [1] https://github.com/openstack/rally/releases > [2] https://github.com/openstack/releases/blob/master/deliverables/_ > independent/rally.yaml#L45 > > -- > Regards, > Jeffrey Zhang > Blog: http://xcodest.me > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] [gate] [all] openstack services footprint lead to oom-kill in the gate
On Thu, Feb 2, 2017 at 6:40 PM, Sean Dague <s...@dague.net> wrote: > On 02/02/2017 11:16 AM, Matthew Treinish wrote: > > > <oops, forgot to finish my though> > > > > We definitely aren't saying running a single worker is how we recommend > people > > run OpenStack by doing this. But it just adds on to the differences > between the > > gate and what we expect things actually look like. > > I'm all for actually getting to the bottom of this, but honestly real > memory profiling is needed here. The growth across projects probably > means that some common libraries are some part of this. The ever growing > requirements list is demonstrative of that. Code reuse is good, but if > we are importing much of a library to get access to a couple of > functions, we're going to take a bunch of memory weight on that > (especially if that library has friendly auto imports in top level > __init__.py so we can't get only the parts we want). > Sounds like the new version of "oslo-incubator" idea. > > Changing the worker count is just shuffling around deck chairs. > > I'm not familiar enough with memory profiling tools in python to know > the right approach we should take there to get this down to individual > libraries / objects that are containing all our memory. Anyone more > skilled here able to help lead the way? > > -Sean > > -- > Sean Dague > http://dague.net > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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][tc] Exposing project team's metadata in README files
On Mon, Jan 9, 2017 at 6:37 PM, Flavio Percoco <fla...@redhat.com> wrote: > On 09/01/17 17:55 +0200, Andrey Kurilin wrote: > >> Hi, Flavio! >> >> Does it possible to create badges per project release? >> > > mmh, it's currently not possible. > > Could you elaborate on why you need a specific tag per release? IS it to > tag the > releases that were done after the inclusion in the big tent? > > OpenStack has a bunch of different tags. "the inclusion in the big tent" is one of tags that should not match to all project releases once project did it. Another one is a "single-vendor" and so on. I think most of tags should be applied per project release. One more "feature request": creation of custom badges(I'm interested in "tested on %(operation_system)s". > Flavio > > > On Mon, Jan 9, 2017 at 3:23 PM, Flavio Percoco <fla...@redhat.com> wrote: >> >> Just a heads up! >>> >>> There are still unmerged patches on this effort. If you have a couple of >>> spare >>> brain cycles, it'd be awesome to get the patches relative to the projects >>> you've >>> +2 votes on in. >>> >>> I'll proceed to abandon remaining patches in 2 weeks from now assuming >>> that >>> projects are not interested in having them. As I mentioned in previous >>> emails, >>> you're free to update the patches to match your project needs. >>> >>> Here's the link to see the remaining patches: >>> https://review.openstack.org/#/q/status:open+topic:project-badges >>> >>> Thanks a lot, >>> Flavio >>> >>> >>> On 12/10/16 14:50 +0200, Flavio Percoco wrote: >>> >>> Greetings, >>>> >>>> One of the common complains about the existing project organization in >>>> the big >>>> tent is that it's difficult to wrap our heads around the many projects >>>> there >>>> are, their current state (in/out the big tent), their tags, etc. >>>> >>>> This information is available on the governance website[0]. Each >>>> official >>>> project team has a page there containing the information related to the >>>> deliverables managed by that team. Unfortunately, I don't think this >>>> page >>>> is >>>> checked often enough and I believe it's not known by everyone. >>>> >>>> In the hope that we can make this information clearer to people browsing >>>> the >>>> many repos (most likely on github), I'd like to propose that we include >>>> the >>>> information of each deliverable in the readme file. This information >>>> would be >>>> rendered along with the rest of the readme (at least on Github, which >>>> might not >>>> be our main repo but it's the place most humans go to to check our >>>> projects). >>>> >>>> Rather than duplicating this information, I'd like to find a way to just >>>> "include it" in the Readme file. As far as showing the "official" badge >>>> goes, I >>>> believe it'd be quite simple. We can do it the same way CI tags are >>>> exposed when >>>> using travis (just include an image). As for the rest of the tags, it >>>> might >>>> require some extra hacking. >>>> >>>> So, before I start digging more into this, I wanted to get other >>>> opinions/ideas >>>> on this topic and how we can make this information more evident to the >>>> rest of >>>> the community (and people not as familiar with our processes as some of >>>> us are). >>>> >>>> Thanks in advance, >>>> Flavio >>>> >>>> [0] http://governance.openstack.org/reference/projects/index.html >>>> >>>> -- >>>> @flaper87 >>>> Flavio Percoco >>>> >>>> >>> >>> >>> -- >>> @flaper87 >>> Flavio Percoco >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.op >>> enstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >> >> -- >> Best regards, >> Andrey Kurilin. >> > > __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > -- > @flaper87 > Flavio Percoco > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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][tc] Exposing project team's metadata in README files
Hi, Flavio! Does it possible to create badges per project release? On Mon, Jan 9, 2017 at 3:23 PM, Flavio Percoco <fla...@redhat.com> wrote: > Just a heads up! > > There are still unmerged patches on this effort. If you have a couple of > spare > brain cycles, it'd be awesome to get the patches relative to the projects > you've > +2 votes on in. > > I'll proceed to abandon remaining patches in 2 weeks from now assuming that > projects are not interested in having them. As I mentioned in previous > emails, > you're free to update the patches to match your project needs. > > Here's the link to see the remaining patches: > https://review.openstack.org/#/q/status:open+topic:project-badges > > Thanks a lot, > Flavio > > > On 12/10/16 14:50 +0200, Flavio Percoco wrote: > >> Greetings, >> >> One of the common complains about the existing project organization in >> the big >> tent is that it's difficult to wrap our heads around the many projects >> there >> are, their current state (in/out the big tent), their tags, etc. >> >> This information is available on the governance website[0]. Each official >> project team has a page there containing the information related to the >> deliverables managed by that team. Unfortunately, I don't think this page >> is >> checked often enough and I believe it's not known by everyone. >> >> In the hope that we can make this information clearer to people browsing >> the >> many repos (most likely on github), I'd like to propose that we include >> the >> information of each deliverable in the readme file. This information >> would be >> rendered along with the rest of the readme (at least on Github, which >> might not >> be our main repo but it's the place most humans go to to check our >> projects). >> >> Rather than duplicating this information, I'd like to find a way to just >> "include it" in the Readme file. As far as showing the "official" badge >> goes, I >> believe it'd be quite simple. We can do it the same way CI tags are >> exposed when >> using travis (just include an image). As for the rest of the tags, it >> might >> require some extra hacking. >> >> So, before I start digging more into this, I wanted to get other >> opinions/ideas >> on this topic and how we can make this information more evident to the >> rest of >> the community (and people not as familiar with our processes as some of >> us are). >> >> Thanks in advance, >> Flavio >> >> [0] http://governance.openstack.org/reference/projects/index.html >> >> -- >> @flaper87 >> Flavio Percoco >> > > > > -- > @flaper87 > Flavio Percoco > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] [Performance] PTG?
Here[*] you can find an etherpad of Performance team. I think Rally team will re-use it. [*] - https://etherpad.openstack.org/p/ptg-performance-team On Sat, Jan 7, 2017 at 9:35 PM, Joe Talerico <jtale...@redhat.com> wrote: > Hey Andrey - Is there a shared etherpad for the Rally/Performance days? > > Thanks, > Joe > > On Wed, Jan 4, 2017 at 11:01 AM, Andrey Kurilin <akuri...@mirantis.com> > wrote: > > Hi, Joe! > > > > It is not a mistake. After a talk with Dina B., we decided to extend > Rally > > session for the wider > > audience and I requested "Rally & Performance team" session. > > > > On Wed, Jan 4, 2017 at 5:29 PM, Joe Talerico <jtale...@redhat.com> > wrote: > >> > >> When I signed up to attend the PTG, Performance was not listed as a > >> option, however on the website it clearly shows Performance is > >> Monday-Tuesday. > >> > >> Is this just a mistake in the event website? > >> > >> Joe > >> > >> > __ > >> 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 > > > > > > > > > > -- > > Best regards, > > Andrey Kurilin. > > > > > __ > > 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 > -- Best regards, Andrey Kurilin. __ 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] [Performance] PTG?
Hi, Joe! It is not a mistake. After a talk with Dina B., we decided to extend Rally session for the wider audience and I requested "Rally & Performance team" session. On Wed, Jan 4, 2017 at 5:29 PM, Joe Talerico <jtale...@redhat.com> wrote: > When I signed up to attend the PTG, Performance was not listed as a > option, however on the website it clearly shows Performance is > Monday-Tuesday. > > Is this just a mistake in the event website? > > Joe > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] Intermittent gate failures across multiple projects
Proposed revert: https://review.openstack.org/414621 On Fri, Dec 23, 2016 at 4:56 PM, Valeriy Ponomaryov < vponomar...@mirantis.com> wrote: > Bug report for problem Andrey and Goutham mentioned is here: > https://bugs.launchpad.net/python-openstackclient/+bug/1652317 > > Valeriy > > On Fri, Dec 23, 2016 at 4:30 PM, Ravi, Goutham < > goutham.pachar...@netapp.com> wrote: > >> Yes. It’s affecting manila tests as well: >> >> >> >> Patch: https://review.openstack.org/#/c/414286/ >> >> Failure: http://logs.openstack.org/86/414286/2/gate/gate-manila-tempe >> st-minimal-dsvm-lvm-ubuntu-xenial/a79dc50/logs/devstacklo >> g.txt.gz#_2016-12-23_13_26_11_470 >> >> >> >> Version of OSC: http://logs.openstack.org/86/4 >> 14286/2/gate/gate-manila-tempest-minimal-dsvm-lvm-ubuntu- >> xenial/a79dc50/logs/devstacklog.txt.gz#_2016-12-23_13_19_04_456 (1.2.0) >> >> Version of OpenStackSDK: http://logs.openstack.org/86/4 >> 14286/2/gate/gate-manila-tempest-minimal-dsvm-lvm-ubuntu- >> xenial/a79dc50/logs/devstacklog.txt.gz#_2016-12-23_13_19_53_450 (0.9.11) >> >> >> >> >> >> *From: *Steve Martinelli <s.martine...@gmail.com> >> *Reply-To: *"OpenStack Development Mailing List (not for usage >> questions)" <openstack-dev@lists.openstack.org> >> *Date: *Friday, December 23, 2016 at 9:16 AM >> *To: *"OpenStack Development Mailing List (not for usage questions)" < >> openstack-dev@lists.openstack.org> >> *Subject: *Re: [openstack-dev] [all] Intermittent gate failures across >> multiple projects >> >> >> >> Those look like they were introduced in the latest release, and related >> to the OpenStackSDK refactoring that hit openstackclient networking >> commands. We actually released the new version because folks were hitting >> similar errors, but for more often used commands (like listing security >> groups or IPs.) >> >> >> >> Is the latest OSC affecting a gate for you? >> >> >> >> >> >> On Dec 23, 2016 8:33 AM, "Andrey Kurilin" <akuri...@mirantis.com> wrote: >> >> Hi eveyone! >> >> I found two more failures related to openstackclient which had appeared >> recently: >> >> - "HttpException: Bad Request" while trying to set quotas via >> openstackclient >> http://logs.openstack.org/43/414543/1/check/gate-rally-dsvm- >> neutron-existing-users-rally/36518f0/console.html#_2016-12- >> 23_11_31_55_070176 >> - "'SecurityGroup' object has no attribute 'keys'" while creating new >> security group >> http://logs.openstack.org/64/355264/5/check/gate-manila-temp >> est-dsvm-mysql-generic-ubuntu-xenial-nv/9ff7aec/logs/devstac >> klog.txt.gz#_2016-12-23_12_53_44_213 >> >> State of latest openstackclient doesn't look good to me :( >> >> >> >> >> >> On Fri, Dec 23, 2016 at 5:24 AM, Tony Breeds <t...@bakeyournoodle.com> >> wrote: >> >> On Thu, Dec 22, 2016 at 04:31:38PM -0800, John Villalovos wrote: >> > We believe the error is caused by a bad wheel for lxml 3.7.0 that was >> > pushed today to PyPi >> > >> > Thanks to everyone working together on this issue in #openstack-infra ! >> > >> > A patch is proposed to blacklist that release and we are testing it now. >> >> The fix is now merged so if you're jobs failed with 'Illegal Instruction' >> feel >> free to recheck without swamping our CI. I believe that eleastic-recheck >> should >> tell you if you match this case. >> >> Thanks to those that found the root cause and worked on the fix >> >> Yours Tony. >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> -- >> >> Best regards, >> Andrey Kurilin. >> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> __ >> OpenSta
Re: [openstack-dev] [all] Intermittent gate failures across multiple projects
Hi Steve, It looks like latest OSC is not the root of issue - the failure appeared several ours ago(5?!) and upper-constrains for OSC was updated several days ago(lxml was blocked more than 5 hours ago). Possibly, update of openstacksdk(https://review.openstack.org/#/c/414366/ ) causes new issues. On Fri, Dec 23, 2016 at 4:16 PM, Steve Martinelli <s.martine...@gmail.com> wrote: > Those look like they were introduced in the latest release, and related to > the OpenStackSDK refactoring that hit openstackclient networking commands. > We actually released the new version because folks were hitting similar > errors, but for more often used commands (like listing security groups or > IPs.) > > Is the latest OSC affecting a gate for you? > > > On Dec 23, 2016 8:33 AM, "Andrey Kurilin" <akuri...@mirantis.com> wrote: > > Hi eveyone! > > I found two more failures related to openstackclient which had appeared > recently: > > - "HttpException: Bad Request" while trying to set quotas via > openstackclient > http://logs.openstack.org/43/414543/1/check/gate-rally-dsvm- > neutron-existing-users-rally/36518f0/console.html#_2016-12- > 23_11_31_55_070176 > - "'SecurityGroup' object has no attribute 'keys'" while creating new > security group > http://logs.openstack.org/64/355264/5/check/gate-manila-temp > est-dsvm-mysql-generic-ubuntu-xenial-nv/9ff7aec/logs/devstac > klog.txt.gz#_2016-12-23_12_53_44_213 > > State of latest openstackclient doesn't look good to me :( > > > On Fri, Dec 23, 2016 at 5:24 AM, Tony Breeds <t...@bakeyournoodle.com> > wrote: > >> On Thu, Dec 22, 2016 at 04:31:38PM -0800, John Villalovos wrote: >> > We believe the error is caused by a bad wheel for lxml 3.7.0 that was >> > pushed today to PyPi >> > >> > Thanks to everyone working together on this issue in #openstack-infra ! >> > >> > A patch is proposed to blacklist that release and we are testing it now. >> >> The fix is now merged so if you're jobs failed with 'Illegal Instruction' >> feel >> free to recheck without swamping our CI. I believe that eleastic-recheck >> should >> tell you if you match this case. >> >> Thanks to those that found the root cause and worked on the fix >> >> Yours Tony. >> >> ____ >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Best regards, > Andrey Kurilin. > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] Intermittent gate failures across multiple projects
Hi eveyone! I found two more failures related to openstackclient which had appeared recently: - "HttpException: Bad Request" while trying to set quotas via openstackclient http://logs.openstack.org/43/414543/1/check/gate-rally-dsvm-neutron-existing-users-rally/36518f0/console.html#_2016-12-23_11_31_55_070176 - "'SecurityGroup' object has no attribute 'keys'" while creating new security group http://logs.openstack.org/64/355264/5/check/gate-manila-tempest-dsvm-mysql-generic-ubuntu-xenial-nv/9ff7aec/logs/devstacklog.txt.gz#_2016-12-23_12_53_44_213 State of latest openstackclient doesn't look good to me :( On Fri, Dec 23, 2016 at 5:24 AM, Tony Breeds <t...@bakeyournoodle.com> wrote: > On Thu, Dec 22, 2016 at 04:31:38PM -0800, John Villalovos wrote: > > We believe the error is caused by a bad wheel for lxml 3.7.0 that was > > pushed today to PyPi > > > > Thanks to everyone working together on this issue in #openstack-infra ! > > > > A patch is proposed to blacklist that release and we are testing it now. > > The fix is now merged so if you're jobs failed with 'Illegal Instruction' > feel > free to recheck without swamping our CI. I believe that eleastic-recheck > should > tell you if you match this case. > > Thanks to those that found the root cause and worked on the fix > > Yours Tony. > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] Storyboard Lives!
Hi! It looks really promising. I like the idea of abandoning launchpad (it is inconvenient at all) and I like "boards" for tasks. But I have one feature request, before I can think seriously about switching to it from my trello board - ability to change colors of UI. Generally I like red and black colors, but it’s just too harsh and my eyes get tired quickly while browsing pages at StoryBoard. On Wed, Dec 21, 2016 at 11:59 PM, Kendall Nelson <kennelso...@gmail.com> wrote: > Hello All, > >As you may or may not have heard, we are still working on moving > towards Storyboard as our task tracker. In an effort to spread awareness > about Storyboard and its capabilities, we’ve decided to write some blog > posts about how it works and how it will be different from Launchpad. The > first post is a general overview of the decision to move to Storyboard from > Launchpad [1]. Please take a few minutes to look it over! > > We will have more blog posts coming after the new year begins (with > everyone taking things easy over the holidays and all there will be a bit > of a gap). The next post’s focus will be a more in depth compare and > contrast of Launchpad and Storyboard. After that, we have a few others > planned, but if there are things you would be interested in hearing about > in more detail that might be good for a blog post, let us know! Also, feel > free to drop in the #storyboard channel if you have questions or attend our > weekly meetings [2]. > > If you are interested in playing around in the Storyboard sandbox [3], > read some of the documentation [4], or just go check it out [5] please do > so as well :) > > Thanks! > > Kendall Nelson (diablo_rojo) & the Storyboard team :) > > [1] https://storyboard-blog.sotk.co.uk/why-storyboard-for-openstack.html > > [2] https://wiki.openstack.org/wiki/StoryBoard > > [3] https://storyboard-dev.openstack.org/ > > [4] http://docs.openstack.org/infra/storyboard/ > > [5] https://storyboard.openstack.org/ > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] Adding CONTRIBUTING.rst files to projects
On Wed, Dec 21, 2016 at 5:46 PM, Andreas Jaeger <a...@suse.com> wrote:
> On 2016-12-21 16:22, Ian Cordasco wrote:
> > [...]
> > That said, I think there are two better places for this information
> > that are already standards in OpenStack:
> >
> > * README.rst
> > * HACKING.rst
> >
> > Most projects include links to the contributing documentation in at
> > least one of these files. I think the effort here is to standardize,
> > albeit in a brand new file, and that's admirable.
>
> If that's the goal - to standardize - then I would expect that we move
> all the documentation out of those files in one place.
>
> Right now, the changes duplicate information that exists - and the new
> information is often wrong. It points to place that do not exist or
> where better places exist. ;(
>
Duplication can be reduced by using `.. include:: ` directive.
>
>
> I'm fine with the status quo - of using the two files that you mention.
> Having contribution information is important,
>
> Andreas
> --
> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: 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
>
--
Best regards,
Andrey Kurilin.
__
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] Adding CONTRIBUTING.rst files to projects
true. Regularly, README.rst includes "how-to contribute" stuff, but "ideal" README should describe a lot of things about projects and it can become huge enough, so new contributors can miss "how-to contribute" section there (README often doesn't have content list at the top of file). +1 on those files. > > > If you look at the gerrit query, some projects have already merged or > > abandoned some of the patches. Let's see if we can come to an > > agreement about how to improve the experience for people finding our > > projects and wanting to collaborate with us. > > > > [1]: https://review.openstack.org/#/q/owner:zhouyunfeng%40inspur. > com+topic:addCONTRIBUTING.rst > > -- > > Ian Cordasco > > > > ________ > __ > > 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 > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] broken rally gate
Sorry folks! We were broken by Keystone, Nova-net, Heat, oslo.db, setuptools(virtualenv) at one moment and it looks like I made a mistake while trying to fix them all. On Fri, Dec 9, 2016 at 3:04 AM, Armando M. <arma...@gmail.com> wrote: > > > On 8 December 2016 at 16:40, Armando M. <arma...@gmail.com> wrote: > >> Hi folks >> >> Chasing down why [1] accidentally broke rally. Please do not recheck, and >> the failure is persistent. >> >> Thanks, >> Armando >> >> [1] https://review.openstack.org/#/c/408020 >> > > https://review.openstack.org/#/c/408870/ should bring sanity back into > the world. > > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] [keystone][devstack][rally][python-novaclient][magnum] switching to keystone v3 by default
On Thu, Dec 1, 2016 at 7:39 PM, Morgan Fainberg <morgan.fainb...@gmail.com> wrote: > On Dec 1, 2016 8:25 AM, "Andrey Kurilin" <akuri...@mirantis.com> wrote: > > > > As I replied at IRC, please do not mix two separate issues! > > Yes, we have several scenarios which are not support keystone v3 yet. It > is an issue, but it is unrelated issue to described in the first mail. > > We have a job which is configured with proper IDENTITY_API_VERSION flag > and should be launched against Keystone v2, but there is only keystone v3 > and it is a real issue. > > > > On Thu, 1 Dec 2016 at 17:48, Lance Bragstad <lbrags...@gmail.com> wrote: > >> > >> FWIW - i'm seeing a common error in several of the rally failures [0] > [1] [2] [3]. Dims also pointed out a few bugs in rally for keystone v3 > support [4]. > >> > >> I checked with the folks in #openstack-containers to see if they were > experiencing anymore fallout, but it looks like the magnum gate is under > control [5]. We're currently in #openstack-keystone talking through options > for the rally situation in case anyone feels like joining. > >> > >> > >> [0] http://logs.openstack.org/87/404887/4/check/gate-rally- > dsvm-neutron-existing-users-rally/ff60a83/console.html#_ > 2016-12-01_08_05_55_268772 > >> [1] http://logs.openstack.org/43/405143/3/check/gate-rally- > dsvm-neutron-existing-users-rally/3ee975b/console.html#_ > 2016-12-01_08_39_02_618302 > >> [2] http://logs.openstack.org/83/394583/26/check/gate-rally- > dsvm-cli/af28c0f/console.html#_2016-12-01_14_09_19_584427 > >> [3] http://logs.openstack.org/83/394583/26/check/gate-rally- > dsvm-neutron-existing-users-rally/26cd009/console.html#_ > 2016-12-01_14_15_17_147016 > >> [4] https://bugs.launchpad.net/rally?field.searchtext=keystone+v3 > >> [5] http://eavesdrop.openstack.org/irclogs/%23openstack-containers/% > 23openstack-containers.2016-12-01.log.html#t2016-12-01T14:57:00 > >> > >> On Thu, Dec 1, 2016 at 6:39 AM, Spyros Trigazis <strig...@gmail.com> > wrote: > >>> > >>> I think for magnum we are OK. > >>> > >>> This job [1] finished using keystone v3 [2] > >>> > >>> Spyros > >>> > >>> [1] http://logs.openstack.org/93/400593/9/check/gate- > functional-dsvm-magnum-api/93e8c14/ > >>> [2] http://logs.openstack.org/93/400593/9/check/gate- > functional-dsvm-magnum-api/93e8c14/logs/devstacklog.txt. > gz#_2016-12-01_11_32_58_033 > >>> > >>> On 1 December 2016 at 12:26, Davanum Srinivas <dava...@gmail.com> > wrote: > >>>> > >>>> It has taken years to get here with a lot of work from many folks. > >>>> > >>>> -1 for Any revert! > >>>> > >>>> https://etherpad.openstack.org/p/v3-only-devstack > >>>> http://markmail.org/message/aqq7itdom36omnf6 > >>>> https://review.openstack.org/#/q/status:merged+project: > openstack-dev/devstack+branch:master+topic:bp/keystonev3 > >>>> > >>>> Thanks, > >>>> Dims > >>>> > >>>> On Thu, Dec 1, 2016 at 5:38 AM, Andrey Kurilin <akuri...@mirantis.com> > wrote: > >>>> > Hi folks! > >>>> > > >>>> > Today devstack team decided to switch to keystone v3 by default[0]. > >>>> > Imo, it is important thing, but it was made in silent, so other > project was > >>>> > unable to prepare to that change. Also, proposed way to select > Keystone API > >>>> > version via devstack configuration doesn't work(IDENTITY_API_VERSION > >>>> > variable doesn't work [1] ). > >>>> > > >>>> > Switching to keystone v3 broke at least Rally and Magnum(based on > comment to > >>>> > [0]) gates. Also, python-novaclient has two separate jobs for > checking > >>>> > compatibility with keystone V2 and V3. One of these jobs became > redundant. > >>>> > > >>>> > That is why I submitted a revert [2] . > >>>> > > >>>> > PS: Please, do not make such changes in silent! > >>>> > > >>>> > [0] - https://review.openstack.org/#/c/386183 > >>>> > [1] - > >>>> > https://github.com/openstack-infra/project-config/blob/ > master/jenkins/jobs/rally.yaml#L70-L74 > >>>> > [2] - https://review.openstack.org/405264 > >>>> > > >>>> > -- &g
Re: [openstack-dev] [keystone][devstack][rally][python-novaclient][magnum] switching to keystone v3 by default
As I replied at IRC, please do not mix two separate issues! Yes, we have several scenarios which are not support keystone v3 yet. It is an issue, but it is unrelated issue to described in the first mail. We have a job which is configured with proper IDENTITY_API_VERSION flag and should be launched against Keystone v2, but there is only keystone v3 and it is a real issue. On Thu, 1 Dec 2016 at 17:48, Lance Bragstad <lbrags...@gmail.com> wrote: > FWIW - i'm seeing a common error in several of the rally failures [0] [1] > [2] [3]. Dims also pointed out a few bugs in rally for keystone v3 support > [4]. > > I checked with the folks in #openstack-containers to see if they were > experiencing anymore fallout, but it looks like the magnum gate is under > control [5]. We're currently in #openstack-keystone talking through options > for the rally situation in case anyone feels like joining. > > > [0] > http://logs.openstack.org/87/404887/4/check/gate-rally-dsvm-neutron-existing-users-rally/ff60a83/console.html#_2016-12-01_08_05_55_268772 > [1] > http://logs.openstack.org/43/405143/3/check/gate-rally-dsvm-neutron-existing-users-rally/3ee975b/console.html#_2016-12-01_08_39_02_618302 > [2] > http://logs.openstack.org/83/394583/26/check/gate-rally-dsvm-cli/af28c0f/console.html#_2016-12-01_14_09_19_584427 > [3] > http://logs.openstack.org/83/394583/26/check/gate-rally-dsvm-neutron-existing-users-rally/26cd009/console.html#_2016-12-01_14_15_17_147016 > [4] https://bugs.launchpad.net/rally?field.searchtext=keystone+v3 > [5] > http://eavesdrop.openstack.org/irclogs/%23openstack-containers/%23openstack-containers.2016-12-01.log.html#t2016-12-01T14:57:00 > > On Thu, Dec 1, 2016 at 6:39 AM, Spyros Trigazis <strig...@gmail.com> > wrote: > > I think for magnum we are OK. > > This job [1] finished using keystone v3 [2] > > Spyros > > [1] > http://logs.openstack.org/93/400593/9/check/gate-functional-dsvm-magnum-api/93e8c14/ > [2] > http://logs.openstack.org/93/400593/9/check/gate-functional-dsvm-magnum-api/93e8c14/logs/devstacklog.txt.gz#_2016-12-01_11_32_58_033 > > On 1 December 2016 at 12:26, Davanum Srinivas <dava...@gmail.com> wrote: > > It has taken years to get here with a lot of work from many folks. > > -1 for Any revert! > > https://etherpad.openstack.org/p/v3-only-devstack > http://markmail.org/message/aqq7itdom36omnf6 > > https://review.openstack.org/#/q/status:merged+project:openstack-dev/devstack+branch:master+topic:bp/keystonev3 > > Thanks, > Dims > > On Thu, Dec 1, 2016 at 5:38 AM, Andrey Kurilin <akuri...@mirantis.com> > wrote: > > Hi folks! > > > > Today devstack team decided to switch to keystone v3 by default[0]. > > Imo, it is important thing, but it was made in silent, so other project > was > > unable to prepare to that change. Also, proposed way to select Keystone > API > > version via devstack configuration doesn't work(IDENTITY_API_VERSION > > variable doesn't work [1] ). > > > > Switching to keystone v3 broke at least Rally and Magnum(based on > comment to > > [0]) gates. Also, python-novaclient has two separate jobs for checking > > compatibility with keystone V2 and V3. One of these jobs became > redundant. > > > > That is why I submitted a revert [2] . > > > > PS: Please, do not make such changes in silent! > > > > [0] - https://review.openstack.org/#/c/386183 > > [1] - > > > https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/rally.yaml#L70-L74 > > [2] - https://review.openstack.org/405264 > > > > -- > > Best regards, > > Andrey Kurilin. > > > > > __ > > 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 > > > > > > -- > Davanum Srinivas :: https://twitter.com/dims > > __ > 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] [keystone][devstack][rally][python-novaclient][magnum] switching to keystone v3 by default
Hi folks! Today devstack team decided to switch to keystone v3 by default[0]. Imo, it is important thing, but it was made in silent, so other project was unable to prepare to that change. Also, proposed way to select Keystone API version via devstack configuration doesn't work(IDENTITY_API_VERSION variable doesn't work [1] ). Switching to keystone v3 broke at least Rally and Magnum(based on comment to [0]) gates. Also, python-novaclient has two separate jobs for checking compatibility with keystone V2 and V3. One of these jobs became redundant. That is why I submitted a revert [2] . PS: Please, do not make such changes in silent! [0] - https://review.openstack.org/#/c/386183 [1] - https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/rally.yaml#L70-L74 [2] - https://review.openstack.org/405264 -- Best regards, Andrey Kurilin. __ 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][tc] Exposing project team's metadata in README files
The same for Rally project... On Thu, Oct 13, 2016 at 2:56 PM, Qiming Teng <teng...@linux.vnet.ibm.com> wrote: > project-navigator? http://www.openstack.org/software/ > > It is often misinterpreted as: OpenStack has 6 core services which are > all mandatory (because they are *core* services) plus 13 optional > services that can be selectively installed. > > I tried hard to find out how the lists are generated, but I failed. > There are at least the following projects which are neither *core* nor > *optional* services: > > cloudkitty > dragonflow > freezer > karbor > kolla > kuryr > mistral > monasca > searchlight > senlin > solum > tacker > vitrage > watcher > > Looks like this is something causing some confusions. Should/can we fix > that? > > Regards, > Qiming > > > On Wed, Oct 12, 2016 at 02:43:45PM -0700, Mike Perez wrote: > > On 14:50 Oct 12, Flavio Percoco wrote: > > > Greetings, > > > > > > One of the common complains about the existing project organization in > the big > > > tent is that it's difficult to wrap our heads around the many projects > there > > > are, their current state (in/out the big tent), their tags, etc. > > > > > > This information is available on the governance website[0]. Each > official > > > project team has a page there containing the information related to the > > > deliverables managed by that team. Unfortunately, I don't think this > page is > > > checked often enough and I believe it's not known by everyone. > > > > Besides the governance site, there is also the project navigator [1] > which is > > a more friendly landing page on projects and their tags. Although it > does not > > today capture separate deliverables. > > > > Assuming the README files aren't being manually updated, I don't have a > problem > > with this idea. > > > > [1] - https://www.openstack.org/software/project-navigator/ > > > > -- > > Mike Perez > > > __________ > 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 > -- Best regards, Andrey Kurilin. __ 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] [Rally][all] Gitter as an alternative way for communication
Hi Thierry, On Fri, Nov 25, 2016 at 12:51 PM, Thierry Carrez <thie...@openstack.org> wrote: > Andrey Kurilin wrote: > > I'm happy to announce our new chats at gitter.im <http://gitter.im> : > > [...] > > While I understand where you're coming from, I would like to remind you > that the OpenStack community standardized on IRC for community > communication. Maintaining alternate communication channels might make > it slightly easier for your team members, but it makes it more difficult > for others in the OpenStack community to follow what is happening, and > participate to Rally development. As I said before, we do not plan to abandon our regular IRC channel and we have a bot for synchronisation messages between gitter and irc channels, so users from Gitter can participate in IRC discussions, and vice versa users from IRC can ping guys from our Gitter channel. It is just an extension of rally communication workflow, not replacement of IRC at all. > This is why as part of the official > OpenStack project team requirements we have usage of IRC baked in. > > IRC is a standard protocol, implemented in a lot of open source clients. > Alternatives like Slack or Gitter are closed-source services with terms > of use (and future decisions on openness and pricing) that may or may > not be acceptable by our community members -- using them creates > fragmentation within the OpenStack community. > > That is not saying that IRC is perfect and that we will never move to > something else. But when we do, it will be as a community (and after an > open community discussion) and not project per project. I can believe that OpenStack community will move from Freenode to another IRC service (if Freenode dies) someday, but moving to another protocol is unbelievable thing for me. OpenStack community will never do it. :) We'd rather maintain IRC protocol by ourself... That is why Rally-community decided to use "not-irc tool" without cross-project discussion. BUT, as I said before, we did it without breaking compatibility with other OpenStack projects and we will not do it.. > It is also > likely to be toward an open protocol supported by open source software, > rather than one specific third-party proprietary web service. > Why? Why we can not use convenient free for opensource projects things? Why not enjoy all the advantages of the modern world?:) It is out of current topic, but why we use inconvenient launchpad instead of bitbucket and so on? > Regards, > > -- > 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 > -- Best regards, Andrey Kurilin. __ 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] [Rally][all] Gitter as an alternative way for communication
Hi folks! I'm happy to announce our new chats at gitter.im : - https://gitter.im/rally-dev/Lobby # main chat for regular communication - https://gitter.im/rally-dev/statuses # chat for gerrit notifications These chats are configured with a simple bot which syncs messages between Gitter and IRC, so we do not plan to abandon our #openstack-rally Freenode channel and you can choose the best messenger for yourself. Long story: I had a talk with several guys some time ago and they mentioned that IRC is not convenient for them enough, even with modern clients like IRCCloud (it is not an advertisement:) ). Also, this topic was raised at Rally work session at Barcelona and we discussed it at our weekly meetings too. Why Gitter? Gitter is a free service from GitHub, so you can use you GitHub account for authentication (everyone has GitHub account) or you can use your twitter account. It provides convenient chats with avatars, quoting, markdown and etc. You do not need an invitation for join us - just go to https://gitter.im/rally-dev/Lobby and push "join room" button. Also, if you want, you can use Gitter IRC tunnel (actually, you do not need it, you can continue use #openstack-rally Freenode channel). Why not slack? Slack is good enough and it is used by another big community - Kubernetes, but, imho, it has at least several limitations: you need to be invited for joining "organization"; the way of switching between organizations are not good enough. -- Best regards, Andrey Kurilin. __ 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] [Rally] broken jobs
Finally, fixes are merged and our jobs work now. On Tue, Nov 22, 2016 at 3:01 PM, Andrey Kurilin <akuri...@mirantis.com> wrote: > Hi Renat, > > As soon as one [1][2] changes will be merged, everything should be > unblocked. > > [1] - https://review.openstack.org/#/c/399752 > [2] - https://review.openstack.org/#/c/400183 > > > On Tue, Nov 22, 2016 at 12:40 PM, Renat Akhmerov <renat.akhme...@gmail.com > > wrote: > >> Andrey, thanks for reporting this. Any estimations on how long it will >> take to fix it? >> >> Renat Akhmerov >> @Nokia >> >> On 19 Nov 2016, at 02:23, Andrey Kurilin <akuri...@mirantis.com> wrote: >> >> yse, I think you are right. >> >> On Fri, Nov 18, 2016 at 4:04 PM, gordon chung <g...@live.ca> wrote: >> >>> this seems related to fact we use datetime type in mysql which requires >>> 5.6.4? (i'm guessing on version). but yes, ubuntu-xenial should have the >>> required mysql. >>> >>> On 18/11/16 07:50 AM, Andrey Kurilin wrote: >>> > Hi stackers, >>> > >>> > I hate to report such things, but most of rally jobs are broken now due >>> > to uncompatibility aodh service with ubuntu-trusty nodes. >>> > >>> > If you find failed rally jobs with >>> > http://paste.openstack.org/show/589707/ in devstacklogs, recheck will >>> > not help. >>> > >>> > I'm working on two changes now for Rally jobs which should unblock and >>> > fix gates: >>> > - Port Rally jobs to use ubuntu-xenial nodes. We had to do it long >>> time ago. >>> > - Disable telemetry services in those jobs which do not need them. >>> > >>> > >>> > -- >>> > Best regards, >>> > Andrey Kurilin. >>> > >>> > >>> > >>> __ >>> > OpenStack Development Mailing List (not for usage questions) >>> > Unsubscribe: openstack-dev-requ...@lists.op >>> enstack.org?subject:unsubscribe >>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> >>> -- >>> gord >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.op >>> enstack.org?subject:unsubscribe >>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >> -- >> Best regards, >> Andrey Kurilin. >> ________ >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Best regards, > Andrey Kurilin. > -- Best regards, Andrey Kurilin. __ 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] [Rally] broken jobs
Hi Renat, As soon as one [1][2] changes will be merged, everything should be unblocked. [1] - https://review.openstack.org/#/c/399752 [2] - https://review.openstack.org/#/c/400183 On Tue, Nov 22, 2016 at 12:40 PM, Renat Akhmerov <renat.akhme...@gmail.com> wrote: > Andrey, thanks for reporting this. Any estimations on how long it will > take to fix it? > > Renat Akhmerov > @Nokia > > On 19 Nov 2016, at 02:23, Andrey Kurilin <akuri...@mirantis.com> wrote: > > yse, I think you are right. > > On Fri, Nov 18, 2016 at 4:04 PM, gordon chung <g...@live.ca> wrote: > >> this seems related to fact we use datetime type in mysql which requires >> 5.6.4? (i'm guessing on version). but yes, ubuntu-xenial should have the >> required mysql. >> >> On 18/11/16 07:50 AM, Andrey Kurilin wrote: >> > Hi stackers, >> > >> > I hate to report such things, but most of rally jobs are broken now due >> > to uncompatibility aodh service with ubuntu-trusty nodes. >> > >> > If you find failed rally jobs with >> > http://paste.openstack.org/show/589707/ in devstacklogs, recheck will >> > not help. >> > >> > I'm working on two changes now for Rally jobs which should unblock and >> > fix gates: >> > - Port Rally jobs to use ubuntu-xenial nodes. We had to do it long time >> ago. >> > - Disable telemetry services in those jobs which do not need them. >> > >> > >> > -- >> > Best regards, >> > Andrey Kurilin. >> > >> > >> > >> __ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: openstack-dev-requ...@lists.op >> enstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> -- >> gord >> >> ________ >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Best regards, > Andrey Kurilin. > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] rally failure in the gate
Dims, thanks! On Mon, Nov 21, 2016 at 1:44 PM, Davanum Srinivas <dava...@gmail.com> wrote: > Andrey, Folks, > > I've fast-tracked the black list: > https://review.openstack.org/400183 > > Thanks, > Dims > > > > On Mon, Nov 21, 2016 at 6:00 AM, Andrey Kurilin <akuri...@mirantis.com> > wrote: > > hi folks! > > > > Neutron gates are broken again. New failure relates to issue with > heatclient > > [*] . > > > > [*] - https://bugs.launchpad.net/python-heatclient/+bug/1643507 > > > > > > > > On Fri, Nov 18, 2016 at 12:51 PM, Andrey Kurilin <akuri...@mirantis.com> > > wrote: > >> > >> Hi stackers! > >> > >> Imo, there is a better solution - just turn off telemetry services[*] :) > >> Neutron jobs do not runs any ceilometer scenarios, so enabling all > telemetry > >> services looks redundant and takes some time while preparing environment > >> (installing devstack). > >> > >> > >> [*] - https://review.openstack.org/#/c/399212 > >> > >> On Fri, Nov 18, 2016 at 12:41 PM, Ihar Hrachyshka <ihrac...@redhat.com> > >> wrote: > >>> > >>> > >>> > On 17 Nov 2016, at 20:32, Armando M. <arma...@gmail.com> wrote: > >>> > > >>> > Hi folks, > >>> > > >>> > Please do not recheck rally failures. > >>> > > >>> > There was a breaking change introduced by aodh [0] that prevented > rally > >>> > to work on trusty. We are switching to xenial as we speak anyway > [1], so the > >>> > glitch should be short lived. > >>> > >>> To give an update, the switch to Xenial occurred, and I see jobs > passing > >>> just fine again. > >>> > >>> Ihar > >>> > >>> > __ > >>> 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 > >> > >> > >> > >> > >> -- > >> Best regards, > >> Andrey Kurilin. > > > > > > > > > > -- > > Best regards, > > Andrey Kurilin. > > > > ____ > __ > > 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 > > > > > > -- > Davanum Srinivas :: https://twitter.com/dims > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] rally failure in the gate
hi folks! Neutron gates are broken again. New failure relates to issue with heatclient [*] . [*] - https://bugs.launchpad.net/python-heatclient/+bug/1643507 On Fri, Nov 18, 2016 at 12:51 PM, Andrey Kurilin <akuri...@mirantis.com> wrote: > Hi stackers! > > Imo, there is a better solution - just turn off telemetry services[*] :) > Neutron jobs do not runs any ceilometer scenarios, so enabling all > telemetry services looks redundant and takes some time while preparing > environment (installing devstack). > > > [*] - https://review.openstack.org/#/c/399212 > > On Fri, Nov 18, 2016 at 12:41 PM, Ihar Hrachyshka <ihrac...@redhat.com> > wrote: > >> >> > On 17 Nov 2016, at 20:32, Armando M. <arma...@gmail.com> wrote: >> > >> > Hi folks, >> > >> > Please do not recheck rally failures. >> > >> > There was a breaking change introduced by aodh [0] that prevented rally >> to work on trusty. We are switching to xenial as we speak anyway [1], so >> the glitch should be short lived. >> >> To give an update, the switch to Xenial occurred, and I see jobs passing >> just fine again. >> >> Ihar >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Best regards, > Andrey Kurilin. > -- Best regards, Andrey Kurilin. __ 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] [Rally] broken jobs
yse, I think you are right. On Fri, Nov 18, 2016 at 4:04 PM, gordon chung <g...@live.ca> wrote: > this seems related to fact we use datetime type in mysql which requires > 5.6.4? (i'm guessing on version). but yes, ubuntu-xenial should have the > required mysql. > > On 18/11/16 07:50 AM, Andrey Kurilin wrote: > > Hi stackers, > > > > I hate to report such things, but most of rally jobs are broken now due > > to uncompatibility aodh service with ubuntu-trusty nodes. > > > > If you find failed rally jobs with > > http://paste.openstack.org/show/589707/ in devstacklogs, recheck will > > not help. > > > > I'm working on two changes now for Rally jobs which should unblock and > > fix gates: > > - Port Rally jobs to use ubuntu-xenial nodes. We had to do it long time > ago. > > - Disable telemetry services in those jobs which do not need them. > > > > > > -- > > Best regards, > > Andrey Kurilin. > > > > > > > __ > > 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 > > > > -- > 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 > -- Best regards, Andrey Kurilin. __ 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] [all] [Rally] broken jobs
Hi stackers, I hate to report such things, but most of rally jobs are broken now due to uncompatibility aodh service with ubuntu-trusty nodes. If you find failed rally jobs with http://paste.openstack.org/show/589707/ in devstacklogs, recheck will not help. I'm working on two changes now for Rally jobs which should unblock and fix gates: - Port Rally jobs to use ubuntu-xenial nodes. We had to do it long time ago. - Disable telemetry services in those jobs which do not need them. -- Best regards, Andrey Kurilin. __ 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] rally failure in the gate
Hi stackers! Imo, there is a better solution - just turn off telemetry services[*] :) Neutron jobs do not runs any ceilometer scenarios, so enabling all telemetry services looks redundant and takes some time while preparing environment (installing devstack). [*] - https://review.openstack.org/#/c/399212 On Fri, Nov 18, 2016 at 12:41 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote: > > > On 17 Nov 2016, at 20:32, Armando M. <arma...@gmail.com> wrote: > > > > Hi folks, > > > > Please do not recheck rally failures. > > > > There was a breaking change introduced by aodh [0] that prevented rally > to work on trusty. We are switching to xenial as we speak anyway [1], so > the glitch should be short lived. > > To give an update, the switch to Xenial occurred, and I see jobs passing > just fine again. > > Ihar > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] [Rally] PTL candidacy
Hi stackers, I'm happy to announce my candidacy for Rally PTL for the Ocata release cycle. Quick introduction of myself: - My contribution to OpenStack started > 2.5 years ago - My first commit to Rally was merged ~ 2,5 years ago - I became Rally core ~2.3 years ago My goals for the Ocata cycle: - simplify review process of Rally plugins(more democracy!) - do regular 3 weeks releases - provide up-to-dated release schedule - finish validation refactoring to be more flexible - port rally verification component to plugin base to support different verifiers - provide subunit output for Rally Task - continue work on Rally as a Service - make rally certification even more user-friendly and cover more use-cases - update docs to cover all aspects of Rally - finish work on new entity - hooks, which allow to execute something on specified points of scenario execution - port all plugins to support Keystone V3 and make V3 as default version - provide a way to deliver rally plugins as python packages - split Rally Core and OpenStack related plugins into 2 repos - nested atomics - trends reports for rally verification -- Best regards, Andrey Kurilin. __ 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] Replace OSTF with Rally
On Mon, Jun 27, 2016 at 4:46 PM, Igor Kalnitsky <ikalnit...@mirantis.com> wrote: > > > On Jun 27, 2016, at 16:23, Alex Schultz <aschu...@mirantis.com> wrote: > > > > I thought Rally was more for benchmarking. Wouldn't Tempest make more > sense? > > According to Rally wiki page [1], it seems they have a verification layer > (Tempest so far). Hm, I wonder does it mean we will need to rewrite our > scenarios for Tempest? > > Rally consists of two main components: Rally Task and Rally Verification. They are totally separated. Task component is fully pluggable and you can run there whatever you want in whatever you want way. Verification component is hardcoded now. It was designed for managing(install, configure) and launching(execute and store results) Tempest. But we have a spec to make this component pluggable too. > - igor > > > [1] https://wiki.openstack.org/wiki/Rally > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] Replace OSTF with Rally
Hi! On Mon, Jun 27, 2016 at 4:23 PM, Alex Schultz <aschu...@mirantis.com> wrote: > > > On Mon, Jun 27, 2016 at 7:10 AM, Vladimir Kozhukalov < > vkozhuka...@mirantis.com> wrote: > >> Dear colleagues, >> >> I'd like to suggest to replace Fuel-ostf with Rally. Rally is quite >> popular project and as far as I know it has all necessary features >> (including dashboard). We only need to implement testing scenarios. >> >> In particular the suggestion is as follows >> >> 1) Implement necessary testing scenarios to achieve feature parity with >> Fuel-ostf (including those which test Fuel HA features). >> 2) Prepare necessary rpm/deb packages (Rally itself + scenarios) >> 3) Modify Fuel-qa so it uses Rally instead of Fuel-ostf. >> 4) Deprecate Fuel-ostf (including removal of ostf tab on UI). I'd prefer >> Fuel users to rely on Rally user interface (both CLI and dashboard). >> >> What do you think? Are there any volunteers to implement this? >> >> > I thought Rally was more for benchmarking. Wouldn't Tempest make more > sense? > > Rally is not only about benchmarking, it provides a flexible interface which allows to do whatever you want:) > -Alex > > >> >> 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 >> >> > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] [rally] "Failed to create the requested number of tenants" error
ist-hypervisors.yaml > - > > > but > > > > > he keeps getting the error "Completed: Exit context: `users`\nTask > > > > > config is invalid: `Unable to setup context 'users': 'Failed to > create > > > > > the requested number of tenants.'`" > > > > > > > > > > This is against an Icehouse environment with Mitaka Rally; When I > run > > > > > Rally with debug logging I see: > > > > > > > > > > 2016-06-08 18:59:24.692 11197 ERROR rally.common.broker > > > EndpointNotFound: > > > > > admin endpoint for identity service in region not found > > > > > > > > > > However I note that $OS_AUTH_URL is set in the Rally deployment... > see > > > > > http://paste.openstack.org/show/509002/ for the full log. > > > > > > > > > > Any ideas you could give me would be much appreciated. Thanks! > > > > > > > > > > --N. > > > > > > > > > > > > > > > > > > > > > > > > __ > > > > > 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 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 > -- Best regards, Andrey Kurilin. __ 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] Nova commands
Hi! Please, launch novaclient in debug mode, i.e `nova --debug list` and share traceback from output. On Tue, Apr 19, 2016 at 2:31 PM, Kenny Ji-work <jenkins-...@qq.com> wrote: > Hi all, > > I have installed openstack mitaka, when I execute any nova's commands with > the result displayed below: > > [root@devstack scripts]# nova list > *ERROR (AttributeError): 'unicode' object has no attribute 'get'* > > I installed openstack as the > http://docs.openstack.org/mitaka/install-guide-rdo/ shows. Is there > somebody who encountered the issue? Thank you for answering! > > Sincerely! > Kenny Ji > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] Proposing Andrey Kurilin for python-novaclient core
I am glad to have joined the Team! On Fri, Apr 15, 2016 at 6:00 PM, Matt Riedemann <mrie...@linux.vnet.ibm.com> wrote: > > > On 4/13/2016 12:53 PM, Matt Riedemann wrote: > >> I'd like to propose that we make Andrey Kurilin core on python-novaclient. >> >> He's been doing a lot of the maintenance the last several months and a >> lot of times is the first to jump on any major issue, does a lot of the >> microversion work, and is also working on cleaning up docs and helping >> me with planning releases. >> >> His work is here [1]. >> >> Review stats for the last 4 months (although he's been involved in the >> project longer than that) [2]. >> >> Unless there is disagreement I plan to make Andrey core by the end of >> the week. >> >> [1] >> >> https://review.openstack.org/#/q/owner:akurilin%2540mirantis.com+project:openstack/python-novaclient >> >> [2] http://stackalytics.com/report/contribution/python-novaclient/120 >> >> > Alright, the yays have it, Andrey is now a part of the > python-novaclient-core group. Welcome, Andrey! > > > -- > > Thanks, > > Matt Riedemann > > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] Gerrit performance
Guys, My twitter-status was published long time ago and it is more about how bad gerrit is itself. I know you are doing your best to make it work. Thanks a lot for your work! On Sun, Apr 10, 2016 at 3:52 PM, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2016-04-10 12:43:06 +0300 (+0300), Andrey Kurilin wrote: > > https://twitter.com/andrey_kurilin/status/681861838263443457 > > A lot of the Infra team (me included) aren't on social media Web > sites like that one, but Andreas Jaeger helpfully mentioned it in > the #openstack-infra IRC channel on Freenode a few minutes ago and I > restarted the service. > > We're still on track to replace the server with one tomorrow that > has twice the memory capacity, and are hoping that relieves the load > issues from the JVM's periodic GC runs. > > http://lists.openstack.org/pipermail/openstack-dev/2016-April/091274.html > -- > 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 > -- Best regards, Andrey Kurilin. __ 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] Gerrit performance
https://twitter.com/andrey_kurilin/status/681861838263443457 On Sun, Apr 10, 2016 at 10:39 AM, Gary Kotton <gkot...@vmware.com> wrote: > Hi, > Is anyone else having problems with gerrit: > >1. Sometimes get a proxy error >2. Performance is very bad > > Thanks > Gary > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] [CI] Tempest configuration in Tripleo CI jobs
> 'bare',
> disk_format => 'qcow2',
> is_public=> 'yes',
> source => '
> http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img',
> }
> glance_image { 'cirros_alt':
> ensure => present,
> container_format => 'bare',
> disk_format => 'qcow2',
> is_public=> 'yes',
> source => '
> http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img',
> }
>
> And then you run actually puppet tempest with configuration values, most
> of them you set by yourself:
>
> class { '::tempest':
>
>
> debug => true,
> use_stderr => false,
> log_file => 'tempest.log',
> tempest_clone_owner => $::id,
> git_clone => true,
> setup_venv => true,
> tempest_clone_path => '/tmp/openstack/tempest',
> lock_path => '/tmp/openstack/tempest',
> tempest_config_file => '/tmp/openstack/tempest/etc/tempest.conf',
> configure_images => true,
> configure_networks => true,
> allow_tenant_isolation => true,
> identity_uri => "${testt::config::keystone_auth_uri}/v2.0",
> identity_uri_v3 => "${testt::config::keystone_auth_uri}/v3",
> admin_username => "${testt::config::os_username}",
> admin_tenant_name => "${testt::config::os_tenant_name}",
> admin_password => "${testt::config::os_password}",
> admin_domain_name => 'Default',
> auth_version => 'v3',
> image_name => 'cirros',
> image_name_alt => 'cirros_alt',
> cinder_available => true,
> glance_available => true,
> horizon_available => $horizon,
> nova_available => true,
> neutron_available => true,
> ceilometer_available => $ceilometer,
> aodh_available => $aodh,
> trove_available => $trove,
> sahara_available => $sahara,
> heat_available => $heat,
> swift_available => true,
> ironic_available => $ironic,
> public_network_name => 'nova',
> dashboard_url => "${testt::config::host_url}",
> flavor_ref => 'pup_tempest_custom_nano',
> flavor_ref_alt => 'pup_tempest_custom_micro',
> image_ssh_user => 'cirros',
> image_alt_ssh_user => 'cirros',
> img_file => 'cirros-0.3.4-x86_64-disk.img',
> compute_build_interval => 10,
> ca_certificates_file => "${testt::config::ca_bundle_cert_path}",
> img_dir => '/tmp/openstack/tempest',
> }
>
> But it's not enough, you need also to make some workarounds and additional
> configurations, for example:
>
> tempest_config { 'object-storage/operator_role':
> value => 'SwiftOperator',
> path => "${tempest_clone_path}/etc/tempest.conf",
> }
> }
>
> After this run puppet on controller node:
>
> sudo puppet apply --verbose --debug --detailed-exitcodes -e "include
> ::testt" | tee ~/puppet_run.log
>
> After everything is finished, you need to copy the folder with tempest to
> your node:
> scp -r -heat-admin@${CONTROLLER}:/tmp/openstack /tmp/
>
> After this run within this directory testr init and run tests:
> /tmp/tempest/tools/with_venv.sh testr init
> /tmp/tempest/tools/with_venv.sh testr run
>
> There are still holes in this configuration and most likely you'd fix it
> by another workarounds and tempest_config runs, because it's still a few of
> skipped tests, so configuration is not full as it would be done with
> config_tempest.py.
> You don't have also any possibility to add custom configuration in running
> the manifest, for each config change you need to change the manifest itself
> which makes it maintenance harder and more complex.
>
> I would say that conclusion is quite obvious for me and it's much easier
> even to write tempest.conf manually from scratch or simple template and use
> 5 bash lines, then use puppet for things it's completely not fit to.
>
> P.S. In this script I used ideas from puppet-openstack-integration and
> packstack projects.
>
> [1] https://review.openstack.org/#/c/295844/
> [2] https://git.openstack.org/openstack-infra/tripleo-ci
>
> --
> Best regards
> Sagi Shnaidman
>
> __
> 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
>
>
--
Best regards,
Andrey Kurilin.
__
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] revert new gerrit
Hi Zago, On Fri, Mar 18, 2016 at 6:35 PM, Zaro <zaro0...@gmail.com> wrote: > There is a new web and android interface that's being developed by > guys at Google however it's not available on our version of Gerrit. I > think it probably won't be ready until Gerrit ver 2.13+ > > web interface (polymer+gerrit = polygerrit): > This interface is already very usable in Gerrit 2.12. Currently it's > only available on the gerrit-review.googlesource.com server. If you > like you can try it out by creating an account there and access this > new UI is "https://gerrit-review.googlesource.com/?polygerrit;. I'm > sure they would welcome your feedback. > > UI of polygerrit looks better, but it is still unusable from mobile device :( > The android interface will be announced soon it's still in early > development at this time. > Which kind of interface it will be? Android app or web-based application which should potentially work for other devices? > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] [all][infra] revert new gerrit
Hi all! I want to start this thread because I'm tired. I spent a lot of time, but I can't review as easy as it was with old interface. New Gerrit is awful. Here are several issues: * It is not possible to review patches at mobile phone. "New" "modern" theme is not adopted for small screens. * Leaving comments is a hard task. Position of page can jump anytime. * It is impossible to turn off hot-keys. position of page changed->I don't see that comment pop-up is closed->continue type several letters->make unexpected things(open edit mode, modify something, save, exit...) * patch-dependency tree is not user-friendly * summary table doesn't include status of patch(I need list to the end of a page to know if patch is merged or not) * there is no button "Comment"/"Reply" at the end of page(after all comments). * it is impossible to turn off "new" search mechanism Does it possible to return old, classic theme? It was a good time when we have old and new themes together... -- Best regards, Andrey Kurilin. __ 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] revert new gerrit
> If you haven't tried gertty yet, I highly recommend it. I have an opened tab with it and I should try it, but I wonder why we need gerrit if it a bad thing for a lot of contributors? Is there an alternative for it? Btw, I'm ready to have local instance of gerrit for myself. But I didn't find a way to configure it to use upstream API. > Someone should make a mobile-native app (android/ios) for gerrit now since the new interface is so bad. Hopefully someone somewhere can come up with the time for it. (I haven't had the time myself). It looks like there is an app for android - https://play.google.com/store/apps/details?id=com.jbirdvegas.mgerrit , but, unfortunately, I have a phone from Apple and I didn't find anything for it. I'm upset that classic theme was able to be used on mobile phones and new one do not... On Fri, Mar 18, 2016 at 5:40 PM, Morgan Fainberg <morgan.fainb...@gmail.com> wrote: > > > On Fri, Mar 18, 2016 at 8:35 AM, Monty Taylor <mord...@inaugust.com> > wrote: > >> On 03/18/2016 08:31 AM, Andrey Kurilin wrote: >> >>> Hi all! >>> >>> I want to start this thread because I'm tired. I spent a lot of time, >>> but I can't review as easy as it was with old interface. New Gerrit is >>> awful. Here are several issues: >>> >>> * It is not possible to review patches at mobile phone. "New" "modern" >>> theme is not adopted for small screens. >>> * Leaving comments is a hard task. Position of page can jump anytime. >>> * It is impossible to turn off hot-keys. position of page changed->I >>> don't see that comment pop-up is closed->continue type several >>> letters->make unexpected things(open edit mode, modify something, save, >>> exit...) >>> * patch-dependency tree is not user-friendly >>> * summary table doesn't include status of patch(I need list to the end >>> of a page to know if patch is merged or not) >>> * there is no button "Comment"/"Reply" at the end of page(after all >>> comments). >>> * it is impossible to turn off "new" search mechanism >>> >>> Does it possible to return old, classic theme? It was a good time when >>> we have old and new themes together... >>> >> >> Sadly no. Upstream is pretty tied to the new very terrible interface. >> We're not sure why. >> >> If you haven't tried gertty yet, I highly recommend it. >> > > Someone should make a mobile-native app (android/ios) for gerrit now since > the new interface is so bad. Hopefully someone somewhere can come up with > the time for it. (I haven't had the time myself). > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] Do we need a microversion to return a 501 from GET os-virtual-interfaces?
Hi! I did not find any usage "virtual_interfaces" with try...except block, so we can easily change error code without new microversion. I'm +1 for proper code. On Mon, Mar 7, 2016 at 6:32 PM, Ken'ichi Ohmichi <ken1ohmi...@gmail.com> wrote: > 2016-03-06 15:41 GMT-08:00 Jay Pipes <jaypi...@gmail.com>: > > On 03/06/2016 02:21 PM, Matt Riedemann wrote: > >> > >> Thanks, good point. I think 400 would be best here. And according to our > >> handy-dandy docs [1] it should be OK to do this without a microversion. > > > > > > Yup, 400 is correct and yes, you should not need a new microversion > addition > > to the API. > > +1 for unnecessary microversion bumping. > > Thanks > Ken Ohmichi > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] [cinder] Proposal: changes to our current testing process
Hi Ivan! On Wed, Mar 2, 2016 at 1:25 PM, Ivan Kolodyazhny <e...@e0ne.info> wrote: > Hi Team, > > Here are my thoughts and proposals how to make Cinder testing process > better. I won't cover "3rd party CI's" topic here. I will share my opinion > about current and feature jobs. > > > Unit-tests > >- Long-running tests. I hope, everybody will agree that unit-tests >must be quite simple and very fast. Unit tests which takes more than 3-5 >seconds should be refactored and/or moved to 'integration' tests. >Thanks to Tom Barron for several fixes like [1]. IMO, we it would be >good to have some hacking checks to prevent such issues in a future. > >- Tests coverage. We don't check it in an automatic way on gates. >Usually, we require to add some unit-tests during code review process. Why >can't we add coverage job to our CI and do not merge new patches, with >will decrease tests coverage rate? Maybe, such job could be voting in a >future to not ignore it. For now, there is not simple way to check coverage >because 'tox -e cover' output is not useful [2]. > > There is a script in Rally which can help you to check coverage rate - https://github.com/openstack/rally/blob/master/tests/ci/cover.sh Functional tests for Cinder > > We introduced some functional tests last month [3]. Here is a patch to > infra to add new job [4]. Because these tests were moved from unit-tests, I > think we're OK to make this job voting. Such tests should not be a > replacement for Tempest. They even could tests Cinder with Fake Driver to > make it faster and not related on storage backends issues. > > > Tempest in-tree tests > > Sean started work on it [5] and I think it's a good idea to get them in > Cinder repo to run them on Tempest jobs and 3-rd party CIs against a real > backend. > > > Functional tests for python-brick-cinderclient-ext > > There are patches that introduces functional tests [6] and new job [7]. > > > Functional tests for python-cinderclient > > We've got a very limited set of such tests and non-voting job. IMO, we can > run them even with Cinder Fake Driver to make them not depended on a > storage backend and make it faster. I believe, we can make this job voting > soon. Also, we need more contributors to this kind of tests. > > > Integrated tests for python-cinderclient > > We need such tests to make sure that we won't break Nova, Heat or other > python-cinderclient consumers with a next merged patch. There is a thread > in openstack-dev ML about such tests [8] and proposal [9] to introduce them > to python-cinderclient. > > > Rally tests > > IMO, it would be good to have new Rally scenarios for every patches like > 'improves performance', 'fixes concurrency issues', etc. Even if we as a > Cinder community don't have enough time to implement them, we have to ask > for them in reviews, openstack-dev ML, file Rally bugs and blueprints if > needed. > > > [1] https://review.openstack.org/#/c/282861/ > [2] http://paste.openstack.org/show/488925/ > [3] https://review.openstack.org/#/c/267801/ > [4] https://review.openstack.org/#/c/287115/ > [5] https://review.openstack.org/#/c/274471/ > [6] https://review.openstack.org/#/c/265811/ > [7] https://review.openstack.org/#/c/265925/ > [8] > http://lists.openstack.org/pipermail/openstack-dev/2016-March/088027.html > [9] https://review.openstack.org/#/c/279432/ > > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > > ______ > 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 > > -- Best regards, Andrey Kurilin. __ 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] python-novaclient region setting
Hi!
>didn't work for me in this particular case because of a bug in novaclient
Can you tell more about bug in novaclient or share a bug report?
On Wed, Feb 24, 2016 at 8:42 AM, Xav Paice <xavpa...@gmail.com> wrote:
> fwiw, the second part of Monty's message is in the docs, sans region - it
> would be a fairly swift change to add that and I'll probably submit a
> gerrit for it soon.
>
> Regards os_client_config,
> http://docs.openstack.org/developer/os-client-config/ is great.
> Unfortunately it didn't work for me in this particular case because of a
> bug in novaclient, but that's beside the point - os_client_config is doing
> exactly the right thing and I'm really happy with that approach in most
> cases (and am changing some of our tooling to reflect that).
>
> On 24 February 2016 at 05:05, Matt Riedemann <mrie...@linux.vnet.ibm.com>
> wrote:
>
>>
>>
>> On 2/22/2016 8:02 AM, Monty Taylor wrote:
>>
>>> On 02/21/2016 11:40 PM, Andrey Kurilin wrote:
>>>
>>>> Hi!
>>>> `novaclient.client.Client` entry-point supports almost the same
>>>> arguments as `novaclient.v2.client.Client`. The difference is only in
>>>> api_version, so you can set up region via `novaclient.client.Client` in
>>>> the same way as `novaclient.v2.client.Client`.
>>>>
>>>
>>> The easiest way to get a properly constructed nova Client is with
>>> os-client-config:
>>>
>>> import os_client_config
>>>
>>> OS_PROJECT_NAME="d8af8a8f-a573-48e6-898a-af333b970a2d"
>>> OS_USERNAME="0b8c435b-cc4d-4e05-8a47-a2ada0539af1"
>>> OS_PASSWORD="REDACTED"
>>> OS_AUTH_URL="http://auth.vexxhost.net;
>>> OS_REGION_NAME="ca-ymq-1"
>>>
>>> client = os_client_config.make_client(
>>> 'compute',
>>> auth_url=OS_AUTH_URL, username=OS_USERNAME,
>>> password=OS_PASSWORD, project_name=OS_PROJECT_NAME,
>>> region_name=OS_REGION_NAME)
>>>
>>> The upside is that the constructor interface is the same for all of the
>>> rest of the client libs too (just change the first argument) - and it
>>> will also read in OS_ env vars or named clouds from clouds.yaml if you
>>> have them set.
>>>
>>> (The 'simplest' way is to put your auth and region information into a
>>> clouds.yaml file like this:
>>>
>>>
>>> http://docs.openstack.org/developer/os-client-config/#site-specific-file-locations
>>>
>>>
>>> Such as:
>>>
>>> # ~/.config/openstack/clouds.yaml
>>> clouds:
>>>vexxhost:
>>> profile: vexxhost
>>> auth:
>>> project_name: d8af8a8f-a573-48e6-898a-af333b970a2d
>>> username: 0b8c435b-cc4d-4e05-8a47-a2ada0539af1
>>> password: REDACTED
>>> region_name: ca-ymq-1
>>>
>>>
>>> And do:
>>>
>>> client = os_client_config.make_client('compute', cloud='vexxhost')
>>>
>>>
>>> If you don't want to do that for some reason but you'd like to construct
>>> a novaclient Client object by hand:
>>>
>>>
>>> from keystoneauth1 import loading
>>> from keystoneauth1 import session as ksa_session
>>> from novaclient import client as nova_client
>>>
>>> OS_PROJECT_NAME="d8af8a8f-a573-48e6-898a-af333b970a2d"
>>> OS_USERNAME="0b8c435b-cc4d-4e05-8a47-a2ada0539af1"
>>> OS_PASSWORD="REDACTED"
>>> OS_AUTH_URL="http://auth.vexxhost.net;
>>> OS_REGION_NAME="ca-ymq-1"
>>>
>>> # Get the auth loader for the password auth plugin
>>> loader = loading.get_plugin_loader('password')
>>> # Construct the auth plugin
>>> auth_plugin = loader.load_from_options(
>>> auth_url=OS_AUTH_URL, username=OS_USERNAME, password=OS_PASSWORD,
>>> project_name=OS_PROJECT_NAME)
>>>
>>> # Construct a keystone session
>>> # Other arguments that are potentially useful here are:
>>> # verify - bool, whether or not to verify SSL connection validity
>>> # cert - SSL cert information
>>> # timout - time in seconds to use for connection level TCP timeouts
>>> session = ksa_session.Session(auth_plugin)
>>>
>>> # Now make the client
>>> # Other arguments you may be interested in:
>>> # service_name - if you need to specify a service name for finding the
>>> # right service in the c
Re: [openstack-dev] [rally]how can I give admin role to rally
Hi!
Since I don't found such scenario in our upstream repo, I assume that this
is your custom plugin and I can propose you several solutions:
1) `nova evacuate` is allowed only for admin user, so you can use admin
client in your scenario without changing roles for users. Also,
`required_openstack` validator will check for you that admin client is
specified for your deployment. An example:
from rally.plugins.openstack import scenario
class MyPlugin(scenario.OpenStackScenario):
"""My awesome plugin."""
@validation.required_openstack(admin=True, users=True)
@scenario.configure()
def some_scenario(self):
# do something with nova via simple user
user_novaclient = self.clients("nova")
server = user_novaclient.servers.boot(...)
# do something with nova via admin user
admin_novaclient = self.admin_clients("nova")
admin_novaclient.servers.evacuate(...)
2) Rally supports "roles" context, which can assign roles to users. If you
specify your task as below, self.clients("nova") will return novaclient
initialized by user with "admin" and "another_name_of_role_if_needed" roles:
---
MyPlugin.some_scenario:
-
runner:
type: "constant"
times: 10
concurrency: 2
context:
users:
tenants: 2
users_per_tenant: 3
roles:
- "admin"
- "another_name_of_role_if_needed"
On Tue, Feb 23, 2016 at 8:20 AM, Wu, Liming <wulm.f...@cn.fujitsu.com>
wrote:
> Hi
>
> When I run a scenario about "nova evacuate **", error message was
> Show as follows. How can I give the admin role to rally user.
>
> 2016-02-23 09:18:25.631 6212 INFO rally.task.runner [-] Task
> e2ad6390-8cde-4ed7-a595-f5c36d5e2a08 | ITER: 0 END: Error Forbidden: User
> does not have admin privileges (HTTP 403) (Request-ID:
> req-45312185-56e5-46c4-a39a-68f5e346715e)
> 2016-02-23 09:18:25.636 5995 INFO
> rally.plugins.openstack.context.cleanup.context [-] Task
> e2ad6390-8cde-4ed7-a595-f5c36d5e2a08 | Starting: user resources cleanup
>
> Best regards
> wuliming
>
>
>
> __
> 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
>
--
Best regards,
Andrey Kurilin.
__
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] python-novaclient region setting
Hi! `novaclient.client.Client` entry-point supports almost the same arguments as `novaclient.v2.client.Client`. The difference is only in api_version, so you can set up region via `novaclient.client.Client` in the same way as `novaclient.v2.client.Client`. On Mon, Feb 22, 2016 at 6:11 AM, Xav Paice <xavpa...@gmail.com> wrote: > Hi, > > In http://docs.openstack.org/developer/python-novaclient/api.html it's > got some pretty clear instructions not to use novaclient.v2.client.Client > but I can't see another way to specify the region - there's more than one > in my installation, and no param for region in novaclient.client.Client > > Shall I hunt down/write a blueprint for that? > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] [all] Python 2.6 should rise from the dead
Hi all, As you may know, support of Python 2.6 was dropped this month from most of OpenStack projects. Also infrastructure team dropped Centos 6.x jobs. I'm ok with dropping Python 2.6 support from the master(Mitaka), but what about stable/kilo and stable/liberty ? Kilo and Liberty were released with Python 2.6 support and most of projects have py26 classifiers there. Without py26 jobs in stable branches, it is hard to backport any changes. Also, requirements for stable/liberty do not contain upper caps for python-*clients and oslo.* libraries, so most of projects already have broken py26 support in Liberty. -- Best regards, Andrey Kurilin. __ 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] Python 2.6 should rise from the dead
>If it had py26 classifiers, that was an error. The list of libraries with py26 classifiers is too huge: astara - stable/kilo, stable/liberty astara-appliance - stable/kilo, stable/liberty astara-horizon - stable/kilo, stable/liberty astara-neutron - stable/kilo, stable/liberty bifrost - stable/liberty ceilometermiddleware - stable/kilo, stable/liberty cloudkitty-dashboard - stable/kilo compute-hyperv - stable/kilo, stable/liberty congress - stable/kilo, stable/liberty debtcollector - stable/kilo, stable/liberty designate - stable/kilo, stable/liberty designate-dashboard - stable/liberty glance_store - stable/kilo group-based-policy - stable/kilo group-based-policy-automation - stable/kilo group-based-policy-ui - stable/kilo instack-undercloud - stable/liberty keystoneauth - stable/liberty keystonemiddleware - stable/kilo magnum - stable/kilo, stable/liberty magnum-ui - stable/liberty manila-ui - stable/kilo, stable/liberty mox3 - stable/liberty networking-bagpipe - stable/kilo, stable/liberty networking-bgpvpn - stable/kilo, stable/liberty networking-hyperv - stable/kilo, stable/liberty networking-infoblox - stable/liberty networking-l2gw - stable/kilo, stable/liberty networking-nec - stable/kilo networking-ovs-dpdk - stable/kilo, stable/liberty networking-plumgrid - stable/kilo, stable/liberty networking-vsphere - stable/kilo, stable/liberty nova-docker - stable/kilo, stable/liberty nova-solver-scheduler - stable/kilo os-brick - stable/liberty os-client-config - stable/liberty oslo-incubator - stable/kilo oslo.cache - stable/liberty oslo.concurrency - stable/kilo, stable/liberty oslo.config - stable/kilo, stable/liberty oslo.context - stable/kilo, stable/liberty oslo.db - stable/kilo, stable/liberty oslo.i18n - stable/kilo, stable/liberty oslo.log - stable/kilo, stable/liberty oslo.messaging - stable/kilo oslo.middleware - stable/kilo, stable/liberty oslo.policy - stable/kilo, stable/liberty oslo.reports - stable/liberty oslo.rootwrap - stable/kilo, stable/liberty oslo.serialization - stable/kilo, stable/liberty oslo.service - stable/liberty oslo.utils - stable/kilo, stable/liberty oslo.versionedobjects - stable/kilo oslo.vmware - stable/kilo, stable/liberty oslosphinx - stable/kilo, stable/liberty oslotest - stable/kilo, stable/liberty pycadf - stable/kilo, stable/liberty python-barbicanclient - stable/kilo, stable/liberty python-ceilometerclient - stable/kilo, stable/liberty python-cinderclient - stable/kilo, stable/liberty python-congressclient - stable/kilo, stable/liberty python-designateclient - stable/kilo, stable/liberty python-glanceclient - stable/kilo, stable/liberty python-group-based-policy-client - stable/kilo python-heatclient - stable/kilo, stable/liberty python-ironicclient - stable/kilo, stable/liberty python-keystoneclient - stable/kilo, stable/liberty python-magnumclient - stable/kilo, stable/liberty python-neutronclient - stable/kilo, stable/liberty python-novaclient - stable/kilo, stable/liberty python-openstackclient - stable/kilo, stable/liberty python-saharaclient - stable/kilo, stable/liberty python-swiftclient - stable/kilo, stable/liberty python-tackerclient - stable/kilo, stable/liberty python-troveclient - stable/kilo, stable/liberty python-zaqarclient - stable/kilo, stable/liberty requirements - stable/kilo, stable/liberty stevedore - stable/liberty swift - stable/kilo tacker - stable/kilo, stable/liberty tacker-horizon - stable/kilo, stable/liberty taskflow - stable/kilo tooz - stable/kilo tripleo-common - stable/liberty yaql - stable/kilo, stable/liberty zaqar - stable/kilo, stable/liberty On Wed, Dec 16, 2015 at 1:52 PM, Andreas Jaeger <a...@suse.com> wrote: > On 2015-12-16 12:33, Andrey Kurilin wrote: > >> Hi all, >> As you may know, support of Python 2.6 was dropped this month from most >> of OpenStack projects. Also infrastructure team dropped Centos 6.x jobs. >> >> I'm ok with dropping Python 2.6 support from the master(Mitaka), but >> what about stable/kilo and stable/liberty ? Kilo and Liberty were >> released with Python 2.6 support and most of projects have py26 >> classifiers there. Without py26 jobs in stable branches, it is hard to >> backport any changes. >> > > Kilo and liberty was not released and neither tested on our server > projects for Python 2.6. If it had py26 classifiers, that was an error. > > It was tested only on the client projects so that new python client > libraries could connect to an older installation. > > Andreas > > Also, requirements for stable/liberty do not contain upper caps for >> python-*clients and oslo.* libraries, so most of projects already have >> broken py26 support in Liberty. >> >> -- >> Best regards, >> Andrey Kurilin. >> >> >> __ >> OpenStack Development Mailing List (not for u
Re: [openstack-dev] [python-novaclient] history of virtual-interface commands
Hi Tomi, It looks like CLI was not added from the beginning of virtual-interface history[1]. Jichenjc works on patch[2] to fix this issue. [1] - https://review.openstack.org/#/c/3368/ [2] - https://review.openstack.org/#/c/254707/ On Thu, Dec 10, 2015 at 1:26 PM, Juvonen, Tomi (Nokia - FI/Espoo) < tomi.juvo...@nokia.com> wrote: > Hi, > > > > Also hitting this as making new microversion and would need to have > support in CLI. Seems CLI works just by bumping API_MAX_VERSION (as I am > only adding one new attribute to existing API). Anyhow cannot do this > because microversion 2.12 is not implemented (actually API_MAX_VERSION is > currently 2.9, but 2.7-2.11 should be under way). > > > > Br, > > Tomi > > > > *From:* EXT Andrey Kurilin [mailto:akuri...@mirantis.com] > *Sent:* Friday, December 04, 2015 3:42 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* [openstack-dev] [python-novaclient] history of > virtual-interface commands > > > > Hi stackers! > > > I have found code in novaclient related to virtual-interfaces > extension[1], but there are no cli commands for it. Since rackspace docs > include reference to `virtual-interface-list` command[2], I wonder, is > there a reason for which commands related to virtual-interfaces are missed > from upstream master? > Does anyone know the history of virtual-interfaces extension and CLI > entrypoint for it? > > > > [1] - > https://github.com/openstack/python-novaclient/blob/2.35.0/novaclient/v2/virtual_interfaces.py > [2] - > http://docs.rackspace.com/servers/api/v2/cs-gettingstarted/content/nova_list_virt_interfaces_for_server.html > > -- > > Best regards, > Andrey Kurilin. > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC
Hi! 15-00 or 16-00 - it does not matter to me :) On Fri, Dec 4, 2015 at 11:46 AM, Dina Belova <dbel...@mirantis.com> wrote: > Dear performance folks, > > There is a suggestion to move our meeting time from 15:00 UTC (Tuesdays > <https://wiki.openstack.org/wiki/Meetings/Performance#Meeting_Times>) to > 16:00 UTC (also Tuesdays > <https://wiki.openstack.org/wiki/Meetings/Performance#Meeting_Times>) to > make them more comfortable for US guys. > > Please leave your +1 / -1 here in the email thread. > > Btw +1 from me :) > > Cheers, > Dina > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] [python-novaclient] history of virtual-interface commands
Hi stackers! I have found code in novaclient related to virtual-interfaces extension[1], but there are no cli commands for it. Since rackspace docs include reference to `virtual-interface-list` command[2], I wonder, is there a reason for which commands related to virtual-interfaces are missed from upstream master? Does anyone know the history of virtual-interfaces extension and CLI entrypoint for it? [1] - https://github.com/openstack/python-novaclient/blob/2.35.0/novaclient/v2/virtual_interfaces.py [2] - http://docs.rackspace.com/servers/api/v2/cs-gettingstarted/content/nova_list_virt_interfaces_for_server.html -- Best regards, Andrey Kurilin. __ 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] [python-novaclient] microversions support
Hi stackers! This week I added 5 patches to enable 2.7-2.11 microversions in novaclient[1][2][3][4][5]. I'm not bragging. Just want to ask everyone who are working on new microversions: Please, do not forget to add support of your microversion to official Nova client. [1] - https://review.openstack.org/#/c/251483 [2] - https://review.openstack.org/#/c/251484 [3] - https://review.openstack.org/#/c/251485 [4] - https://review.openstack.org/#/c/251486 [5] - https://review.openstack.org/#/c/253095 -- Best regards, Andrey Kurilin. __ 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] [python-novaclient] microversions support
+1 for Kevin's proposal. On Fri, Dec 4, 2015 at 8:37 PM, Chen CH Ji <jiche...@cn.ibm.com> wrote: > +1 , added a doc change just now https://review.openstack.org/#/c/253644 > > -"Kevin L. Mitchell" <kevin.mitch...@rackspace.com> wrote: - > To: <openstack-dev@lists.openstack.org> > From: "Kevin L. Mitchell" <kevin.mitch...@rackspace.com> > Date: 12/04/2015 06:25PM > Subject: Re: [openstack-dev] [nova] [python-novaclient] microversions > support > > > On Fri, 2015-12-04 at 18:58 +0200, Andrey Kurilin wrote: > > This week I added 5 patches to enable 2.7-2.11 microversions in > > novaclient[1][2][3][4][5]. I'm not bragging. Just want to ask everyone > > who are working on new microversions: Please, do not forget to add > > support of your microversion to official Nova client. > > Perhaps this is something we should add to the review guidelines—no API > change can be merged to nova unless there is a pending change to > novaclient to add support? We already more or less enforce the criteria > that no addition to novaclient can be added unless the corresponding > nova change has been merged… > -- > Kevin L. Mitchell <kevin.mitch...@rackspace.com> > 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 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 > > -- Best regards, Andrey Kurilin. __ 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] [QA][Tempest] Use tempest-config for tempest-cli-improvements
Sorry for wrong numbers. The bug-fix for issue with counters is merged. Correct numbers(latest result from rally's gate[1]): - total number of executed tests: 1689 - success: 1155 - skipped: 534 (neutron,heat,sahara,ceilometer are disabled. [2] should enable them) - failed: 0 [1] - http://logs.openstack.org/27/246627/11/gate/gate-rally-dsvm-verify-full/800bad0/rally-verify/7_verify_results_--html.html.gz [2] - https://review.openstack.org/#/c/250540/ On Thu, Nov 26, 2015 at 3:23 PM, Yaroslav Lobankov <yloban...@mirantis.com> wrote: > Hello everyone, > > Yes, I am working on this now. We have some success already, but there is > a lot of work to do. Of course, some things don't work ideally. For > example, in [2] from the previous letter we have not 24 skipped tests, > actually much more. So we have a bug somewhere :) > > Regards, > Yaroslav Lobankov. > > On Thu, Nov 26, 2015 at 3:59 PM, Andrey Kurilin <akuri...@mirantis.com> > wrote: > >> Hi! >> Boris P. and I tried to push a spec[1] for automation tempest config >> generator, but we did not succeed to merge it. Imo, qa-team doesn't want to >> have such tool:( >> >> >However, there is a big concern: >> >If the script contain a bug and creates the configuration which makes >> >most tests skipped, we cannot do enough tests on the gate. >> >Tempest contains 1432 tests and difficult to detect which tests are >> >skipped as unexpected. >> >> Yaroslav Lobankov is working on improvement for tempest config generator >> in Rally. Last time when we launch full tempest run[2], we got 1154 success >> tests and only 24 skipped. Also, there is a patch, which adds x-fail >> mechanism(it based on subunit-filter): you can transmit a file with test >> names + reasons and rally will modify results. >> >> [1] - https://review.openstack.org/#/c/94473/ >> >> [2] - >> http://logs.openstack.org/49/242849/8/check/gate-rally-dsvm-verify/e91992e/rally-verify/7_verify_results_--html.html.gz >> >> On Thu, Nov 26, 2015 at 1:52 PM, Ken'ichi Ohmichi <ken1ohmi...@gmail.com> >> wrote: >> >>> Hi Daniel, >>> >>> Thanks for pointing this up. >>> >>> 2015-11-25 1:40 GMT+09:00 Daniel Mellado <daniel.mellado...@ieee.org>: >>> > Hi All, >>> > >>> > As you might already know, within Red Hat's tempest fork, we do have >>> one >>> > tempest configuration script which was built in the past by David >>> Kranz [1] >>> > and that's been actively used in our CI system. Regarding this topic, >>> I'm >>> > aware that quite some effort has been done in the past [2] and I would >>> like >>> > to complete the implementation of this blueprint/spec. >>> > >>> > My plan would be to have this script under the /tempest/cmd or >>> > /tempest/tools folder from tempest so it can be used to configure not >>> the >>> > tempest gate but any cloud we'd like to run tempest against. >>> > >>> > Adding the configuration script was discussed briefly at the Mitaka >>> summit >>> > in the QA Priorities meting [3]. I propose we use the existing >>> etherpad to >>> > continue the discussion around and tracking of implementing "tempest >>> > config-create" using the downstream config script as a starting point. >>> [4] >>> > >>> > If you have any questions, comments or opinion, please let me know. >>> >>> This topic have happened several times, and I also felt this kind of >>> tool was very useful for Tempest users, because Tempest contains 296 >>> options($ grep cfg * -R | grep Opt | wc -l) now and it is difficult to >>> set the configuration up. >>> However, there is a big concern: >>> If the script contain a bug and creates the configuration which makes >>> most tests skipped, we cannot do enough tests on the gate. >>> Tempest contains 1432 tests and difficult to detect which tests are >>> skipped as unexpected. >>> Actually we faced unexpected skipped tests on the gate before due to >>> some bug, then the problem has been fixed. >>> But I can imagine this kind of problem happens after implementing this >>> kind of script. >>> >>> So now I am feeling Tempest users need to know what cloud they want to >>> test with Tempest, and need to know what tests run with Tempest. >>> Testers need to know what test target/items they are testing basically. >>> >>> Thanks >>> Ken O
Re: [openstack-dev] [QA][Tempest] Use tempest-config for tempest-cli-improvements
Hi! Boris P. and I tried to push a spec[1] for automation tempest config generator, but we did not succeed to merge it. Imo, qa-team doesn't want to have such tool:( >However, there is a big concern: >If the script contain a bug and creates the configuration which makes >most tests skipped, we cannot do enough tests on the gate. >Tempest contains 1432 tests and difficult to detect which tests are >skipped as unexpected. Yaroslav Lobankov is working on improvement for tempest config generator in Rally. Last time when we launch full tempest run[2], we got 1154 success tests and only 24 skipped. Also, there is a patch, which adds x-fail mechanism(it based on subunit-filter): you can transmit a file with test names + reasons and rally will modify results. [1] - https://review.openstack.org/#/c/94473/ [2] - http://logs.openstack.org/49/242849/8/check/gate-rally-dsvm-verify/e91992e/rally-verify/7_verify_results_--html.html.gz On Thu, Nov 26, 2015 at 1:52 PM, Ken'ichi Ohmichi <ken1ohmi...@gmail.com> wrote: > Hi Daniel, > > Thanks for pointing this up. > > 2015-11-25 1:40 GMT+09:00 Daniel Mellado <daniel.mellado...@ieee.org>: > > Hi All, > > > > As you might already know, within Red Hat's tempest fork, we do have one > > tempest configuration script which was built in the past by David Kranz > [1] > > and that's been actively used in our CI system. Regarding this topic, I'm > > aware that quite some effort has been done in the past [2] and I would > like > > to complete the implementation of this blueprint/spec. > > > > My plan would be to have this script under the /tempest/cmd or > > /tempest/tools folder from tempest so it can be used to configure not the > > tempest gate but any cloud we'd like to run tempest against. > > > > Adding the configuration script was discussed briefly at the Mitaka > summit > > in the QA Priorities meting [3]. I propose we use the existing etherpad > to > > continue the discussion around and tracking of implementing "tempest > > config-create" using the downstream config script as a starting point. > [4] > > > > If you have any questions, comments or opinion, please let me know. > > This topic have happened several times, and I also felt this kind of > tool was very useful for Tempest users, because Tempest contains 296 > options($ grep cfg * -R | grep Opt | wc -l) now and it is difficult to > set the configuration up. > However, there is a big concern: > If the script contain a bug and creates the configuration which makes > most tests skipped, we cannot do enough tests on the gate. > Tempest contains 1432 tests and difficult to detect which tests are > skipped as unexpected. > Actually we faced unexpected skipped tests on the gate before due to > some bug, then the problem has been fixed. > But I can imagine this kind of problem happens after implementing this > kind of script. > > So now I am feeling Tempest users need to know what cloud they want to > test with Tempest, and need to know what tests run with Tempest. > Testers need to know what test target/items they are testing basically. > > Thanks > Ken Ohmichi > > --- > > > --- > > [1] > > > https://github.com/redhat-openstack/tempest/blob/master/tools/config_tempest.py > > [2] > https://blueprints.launchpad.net/tempest/+spec/tempest-config-generator > > [3] https://etherpad.openstack.org/p/mitaka-qa-priorities > > [4] https://etherpad.openstack.org/p/tempest-cli-improvements > > > > > https://github.com/openstack/qa-specs/blob/master/specs/tempest/tempest-cli-improvements.rst > > > > > __ > > 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 > -- Best regards, Andrey Kurilin. __ 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] Getting rid of Docker containers on the Fuel master node
Hi!
I'm not fuel developer, so opinion below is based on user-view.
As far as I remember from the last usage of fuel master node, there was
Centos + py26 installation. Python 2.6 is old enough and sometimes it is
hard to launch some application on fuel node without docker (image with
py27/py3). Are you planning to provide py27 at least or my note is outdated
and I can already use py27 from the box?
On Thu, Nov 19, 2015 at 4:59 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> Dear colleagues,
>
> As might remember, we introduced Docker containers on the master node a
> while ago when we implemented first version of Fuel upgrade feature. The
> motivation behind was to make it possible to rollback upgrade process if
> something goes wrong.
>
> Now we are at the point where we can not use our tarball based upgrade
> approach any more and those patches that deprecate upgrade tarball has been
> already merged. Although it is a matter of a separate discussion, it seems
> that upgrade process rather should be based on kind of backup and restore
> procedure. We can backup Fuel data on an external media, then we can
> install new version of Fuel from scratch and then it is assumed backed up
> Fuel data can be applied over this new Fuel instance. The procedure itself
> is under active development, but it is clear that rollback in this case
> would be nothing more than just restoring from the previously backed up
> data.
>
> As for Docker containers, still there are potential advantages of using
> them on the Fuel master node, but our current implementation of the feature
> seems not mature enough to make us benefit from the containerization.
>
> At the same time there are some disadvantages like
>
>- it is tricky to get logs and other information (for example, rpm
>-qa) for a service like shotgun which is run inside one of containers.
>- it is specific UX when you first need to run dockerctl shell
>{container_name} and then you are able to debug something.
>- when building IBP image we mount directory from the host file system
>into mcollective container to make image build faster.
>- there are config files and some other files which should be shared
>among containers which introduces unnecessary complexity to the whole
>system.
>- our current delivery approach assumes we wrap into rpm/deb packages
>every single piece of the Fuel system. Docker images are not an exception.
>And as far as they depend on other rpm packages we forced to build
>docker-images rpm package using kind of specific build flow. Besides this
>package is quite big (300M).
>- I'd like it to be possible to install Fuel not from ISO but from RPM
>repo on any rpm based distribution. But it is double work to support both
>Docker based and package based approach.
>
> Probably some of you can give other examples. Anyway, the idea is to get
> rid of Docker containers on the master node and switch to plane package
> based approach that we used before.
>
> As far as there is nothing new here, we just need to use our old site.pp
> (with minimal modifications), it looks like it is possible to implement
> this during 8.0 release cycle. If there are no principal objections, please
> give me a chance to do this ASAP (during 8.0), I know it is a huge risk for
> the release, but still I think I can do this.
>
>
>
>
> 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
>
>
--
Best regards,
Andrey Kurilin.
__
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] [oslo] Graduate cliutils.py into oslo.utils
On Tue, Nov 10, 2015 at 4:25 PM, Sean Dague <s...@dague.net> wrote: > On 11/10/2015 08:24 AM, Andrey Kurilin wrote: > >>It was also proposed to reuse openstackclient or the openstack SDK. > > > > Openstack SDK was proposed a long time ago(it looks like it was several > > cycles ago) as "alternative" for cliutils and apiclient, but I don't > > know any client which use it yet. Maybe openstacksdk cores should try to > > port any client as an example of how their project should be used. > > The SDK is targeted for end user applications, not service clients. I do > get there was lots of confusion over this, but SDK is not the answer > here for service clients. > Ok, thanks for explanation, but there is another question in my head: If openstacksdk is not for python-*clients, why apiclient(which is actually used by python-*clients) was marked as deprecated due to openstacksdk? > > The service clients are *always* going to have to exist in some form. > Either as libraries that services produce, or by services deciding they > don't want to consume the libraries of other clients and just put a > targeted bit of rest code in their own tree to talk to other services. > > -Sean > > -- > Sean Dague > http://dague.net > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] [oslo] Graduate apiclient library
y to the new apiclient library and implement > find_resource method in the manila client. > We prefer to implement option #1. > > > Please have a look at it and let us know your suggestions on the same. > Currently we are having Diwali Vacation in India and once we are back from > the vacation, based on your inputs I will update the oslo-specs [3] and > upload it for community review. > > [1]: > https://mitakadesignsummit.sched.org/event/a98e66b41bf5a8bec8db81dd15f77671 > [2]: > https://docs.google.com/spreadsheets/d/1ZpnEl5QoZz6kv4_ElvqIZULQ4UrVFkxmIuUo_zsyVnE > [3]: https://review.openstack.org/#/c/235200/ > > Thank you in advance. > > Abhishek Kekane > > __ > Disclaimer: This email and any attachments are sent in strictest confidence > for the sole use of the addressee and may contain legally privileged, > confidential, and proprietary data. If you are not the intended recipient, > please advise the sender by replying promptly to this email and then delete > and destroy this email and any attachments without any further use, copying > or forwarding. > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] [oslo] Graduate cliutils.py into oslo.utils
>It was also proposed to reuse openstackclient or the openstack SDK. Openstack SDK was proposed a long time ago(it looks like it was several cycles ago) as "alternative" for cliutils and apiclient, but I don't know any client which use it yet. Maybe openstacksdk cores should try to port any client as an example of how their project should be used. On Tue, Nov 10, 2015 at 12:29 PM, Victor Stinner <vstin...@redhat.com> wrote: > Hi, > > At Tokyo, we discussed quickly what to do with cliutils.py of > oslo-incubator, but for me the plan is not really concrete. > > https://etherpad.openstack.org/p/mitaka-oslo-incubator-cleanup > > I don't like dims' suggestion to move code inside clients, it means > duplicating 280 lines of python in 11 clients. > > It was also proposed to reuse openstackclient or the openstack SDK. I > don't understand how novaclient can use openstackclient, since > openstackclient depends on python-novaclient... The OpenStack SDK project > is also a large library no? (I don't know well the OpenStack SDK project.) > > I would prefer to move cliutils.py to oslo.utils. Only 3 clients use > cliutils.py but don't depend on oslo.utils yet. The 8 remaining clients > using cliutils.py already depends on oslo.utils. > > An alternative is to create yet another oslo library. But it means > creating a library for a single file of 280 lines. > > What do you think? > > -- > > On 29 "python-*client" projects, I found 11 clients using cliutils.py: > > python-ceilometerclient > python-cloudkittyclient > python-heatclient > python-ironicclient > python-magnumclient > python-manilaclient > python-mistralclient > python-novaclient > python-saharaclient > python-solumclient > python-tuskarclient > > 9 clients are almost synchronized with oslo-incubator: only the new > optional 'dict_value' parameter of the print_list() function is missing, > not a big deal (since the parameter is optional, it doesn't break the API). > > magnumclient and mistralclient have larger changes. > > magnumclient adds a recursive keys_and_vals_to_strs() function which casts > all dictionary keys and values to string. We may copy this feature in the > upstream code (oslo incubator), it makes sense to me. > > cliutils.py of mistralclient looks outdated, but a find_resource() > function was also added. We can move find_resource() out of cliutils.py, to > put it somewhere in mistralclient. > > On the 11 clients using cliutils.py, 8 depend oslo.utils, whereas 3 don't. > > Victor > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] [murano] python versions
Hi folks! Can anyone share status of porting muranoclient to Python 3? On Tue, Jun 16, 2015 at 4:54 PM, Serg Melikyan <smelik...@mirantis.com> wrote: > Stan, +100500 > > On Fri, Jun 12, 2015 at 3:13 PM, Stan Lagun <sla...@mirantis.com> wrote: > > > > I'd rather go with Heat approach (job first) because it makes easier to > track what is left to port to Py34 and track progress in this area > > > > Sincerely yours, > > Stan Lagun > > Principal Software Engineer @ Mirantis > > > > > > On Mon, Jun 8, 2015 at 2:46 PM, Kirill Zaitsev <kzait...@mirantis.com> > wrote: > >> > >> I’ve looked into several OS projects, and they first seen to implement > py3 support and create a job later. (Except for heat. They already have a > non-voting py34, which seem to fail every time =)) > >> > >> I suggest we do the same: first make murano work on py34, then make a > py34 job. I’ll file a blueprint shortly. > >> > >> -- > >> Kirill Zaitsev > >> Murano team > >> Software Engineer > >> Mirantis, Inc > >> > >> On 2 Jun 2015 at 15:58:17, Serg Melikyan (smelik...@mirantis.com) > wrote: > >> > >> Hi Kirill, > >> > >> I agree with Alexander that we should not remove support for python > >> 2.6 in python-muranoclient. > >> > >> Regarding adding python-3 jobs - great idea! But we need to migrate > >> python-muranoclient to yaql 1.0 first and then add python-3 jobs, > >> because previous versions of yaql are not compatible with python-3. > >> > >> On Tue, Jun 2, 2015 at 3:33 PM, Alexander Tivelkov > >> <ativel...@mirantis.com> wrote: > >> > Hi Kirill, > >> > > >> > Client libraries usually have wider range of python requirements, as > they > >> > may be run on various kinds of legacy environments, including the > ones with > >> > python 2.6. only. > >> > Murano is definitely not the only project in Openstack which still > maintains > >> > py26 compatibility for its client: nova, glance, cinder and other > integrated > >> > ones do this. > >> > > >> > So, I would not drop py26 support for client code without any good > reasons > >> > to. Are there any significant reasons to do it? > >> > Regarding py3.4 - this is definitely a good idea. > >> > > >> > > >> > -- > >> > Regards, > >> > Alexander Tivelkov > >> > > >> > On Tue, Jun 2, 2015 at 3:04 PM, Kirill Zaitsev <kzait...@mirantis.com > > > >> > wrote: > >> >> > >> >> It seems that python-muranoclient is the last project from > murano-official > >> >> group, that still supports python2.6. Other projects do not have a > 2.6 > >> >> testing job (correct me if I’m wrong). > >> >> > >> >> Personally I think it’s time to drop support for 2.6 completely, and > add > >> >> (at least non-voting) jobs with python3.4 support tests. > >> >> It seems to fit the whole process of moving OS projects towards > python 3: > >> >> https://etherpad.openstack.org/p/liberty-cross-project-python3 > >> >> > >> >> What do you think? Does anyone have any objections? > >> >> > >> >> -- > >> >> Kirill Zaitsev > >> >> Murano team > >> >> Software Engineer > >> >> 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 > >> > > >> > >> > >> > >> -- > >> Serg Melikyan, Senior Software Engineer at Mirantis, Inc. > >> http://mirantis.com | smelik...@mirantis.com > >> > >> > __
Re: [openstack-dev] [cinder][nova] gate-cinder-python34 failing test_nova_timeout after novaclient 2.33 release
1/ >>> >>> At least with the cinder change above we're OK for mitaka, and >>> logstash >>> isn't yet showing failures for cinder in stable/liberty, but >>> given the >>> requirements there it will be a failure in cinder python34 >>> tests in >>> stalbe/liberty also - so we can backport the cinder fix or >>> block the >>> 2.33 novaclient version on stable/liberty global-requirements >>> depending >>> on what we do with the proposed novaclient revert. >>> >>> >>> I have an alternative to the revert here: >>> >>> https://review.openstack.org/#/c/239963/ >>> >>> That makes novaclient.exceptions.RequestTimeout extend >>> requests.Timeout so that older cinder continues to work. >>> >>> I also have changes to block novaclient 2.33.0 in g-r on master and >>> stable/liberty: >>> >>> >>> >>> https://review.openstack.org/#/q/I6e7657b60308b30eed89b269810c1f37cce43063,n,z >>> >>> >>> I personally think we need to block 2.33.0 since it breaks cinder, >>> then release a new version of novaclient with either the revert or >>> the alternative change to extend requests.Timeout. >>> >>> If we block novaclient 2.33.0 then we can also revert the workaround >>> in cinder (which would start breaking if we reverted the new >>> exception type out of novaclient w/o blacklisting 2.33 first). >>> >>> >>> -- >>> >>> Thanks, >>> >>> Matt Riedemann >>> >>> >>> >>> >>> __ >>> >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> >>> <http://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 >>> >>> >> The novaclient revert patch is approved: >> >> https://review.openstack.org/#/c/239941/ >> >> Once that is merged I'll propose a release request for novaclient. >> >> I've got g-r patches for master and stable/liberty to block 2.33: >> >> >> https://review.openstack.org/#/q/I6e7657b60308b30eed89b269810c1f37cce43063,n,z >> >> >> Once those land and we've synced the change to cinder, we can revert the >> cinder workaround. >> >> > So the revert is merged [1] but now I'm stuck as to the version and/or git > commit to use for the next release. > > The changes since 2.33.0 are: > > mriedem@ubuntu:~/git/python-novaclient$ git log --oneline --no-merges > 2.33.0.. > 63c7a57 Revert "Do not expose exceptions from requests library" > 217e7c1 Updated from global requirements > 0cd5812 Remove novaclient.v1_1 module > > And when I requested the 2.33.0 release [2], it was on 217e7c1 but they > changed it to be w/o 0cd5812 because that is considered a backward > incompatible change. But it was released with 2961e82 which was the > backward incompatible requests exception change, which we now have a fix > for that we want to release, but would include 0cd5812. > > So do we just release novaclient trunk as 3.0? We still have the g-r > blacklist changes for 2.33.0 in mitaka and liberty so we wouldn't be using > that version in tests (assuming that's merged in g-r). So then people have > to move up to 3.0 if they want the latest novaclient changes. > > This is a bit gross. > > [1] https://review.openstack.org/#/c/239941/ > [2] https://review.openstack.org/#/c/239450/ > > > -- > > Thanks, > > Matt Riedemann > > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] how to address boot from volume failures
>1) fix the client without a revert
I prefer to go with this option, since fix already done and pending review.
>This means that until people upgrade their
>client they loose access to this function on the server.
This applies to any of the proposed options.
On Thu, Oct 1, 2015 at 12:03 AM, Sean Dague <s...@dague.net> wrote:
> Today we attempted to branch devstack and grenade for liberty, and are
> currently blocked because in liberty with openstack client and
> novaclient, it's not possible to boot a server from volume using just
> the volume id.
>
> That's because of this change in novaclient -
> https://review.openstack.org/#/c/221525/
>
> That was done to resolve the issue that strong schema validation in Nova
> started rejecting the kinds of calls that novaclient was making for boot
> from volume, because the bdm 1 and 2 code was sharing common code and
> got a bit tangled up. So 3 bdm 2 params were being sent on every request.
>
> However, https://review.openstack.org/#/c/221525/ removed the ==1 code
> path. If you pass in just {"vda": "$volume_id"} the code falls through,
> volume id is lost, and nothing is booted. This is how the devstack
> exercises and osc recommends booting from volume. I expect other people
> might be doing that as well.
>
> There seem to be a few options going forward:
>
> 1) fix the client without a revert
>
> This would bring back a ==1 code path, which is basically just setting
> volume_id, and move on. This means that until people upgrade their
> client they loose access to this function on the server.
>
> 2) revert the client and loose up schema validation
>
> If we revert the client to the old code, we also need to accept the fact
> that novaclient has been sending 3 extra parameters to this API call
> since as long as people can remember. We'd need a nova schema relax to
> let those in and just accept that people are going to pass those.
>
> 3) fix osc and novaclient cli to not use this code path. This will also
> require everyone upgrades both of those to not explode in the common
> case of specifying boot from volume on the command line.
>
> I slightly lean towards #2 on a compatibility front, but it's a chunk of
> change at this point in the cycle, so I don't think there is a clear win
> path. It would be good to collect opinions here. The bug tracking this
> is - https://bugs.launchpad.net/python-openstackclient/+bug/1501435
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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
>
--
Best regards,
Andrey Kurilin.
__
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][python-novaclient] Functional test fail due to publicURL endpoint for volume service not found
Hi! It looks like cause of issue is a disabling Cinder API V1 in gates by default( http://lists.openstack.org/pipermail/openstack-dev/2015-September/075689.html) which was merged yesterday( https://review.openstack.org/#/c/194726/17 ). Since Cinder V1 is disabled, python-novaclient has several issues: - "nova volume-* does not work when using cinder v2 API" - https://bugs.launchpad.net/python-novaclient/+bug/1392846 - "nova volume-* managers override service_type to 'volume', which is missed in gates" - https://bugs.launchpad.net/python-novaclient/+bug/1501258 On Wed, Sep 30, 2015 at 5:56 AM, Zhenyu Zheng <zhengzhenyul...@gmail.com> wrote: > Hi, all > > I submitted a patch for novaclient last night: > https://review.openstack.org/#/c/228769/ , and it turns out the > functional test has failed due to: publicURL endpoint for volume service > not found. I also found out that another novaclient patch: > https://review.openstack.org/#/c/217131/ also fails due to this error, so > this must be a bug. Any idea on how to fix this? > > Thanks, > > BR, > > Zheng > > __ > 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 > > -- Best regards, Andrey Kurilin. __ 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] [murano] Fix order of arguments in assertEqual
Hi everyone! I agree that wrong order of arguments misleads while debugging errors, BUT how we can prevent regression? Imo, this is not a good idea to make patches like https://review.openstack.org/#/c/64415/ in each release(without check in CI, such patches are redundant). PS: This question relates not only for murano. On Thu, Sep 24, 2015 at 11:48 AM, Kekane, Abhishek < abhishek.kek...@nttdata.com> wrote: > Hi, > > There is a bug for this, you can add murano projects to this bug. > > https://bugs.launchpad.net/heat/+bug/1259292 > > Thanks, > > Abhishek Kekane > > -Original Message- > From: Bulat Gaifullin [mailto:bgaiful...@mirantis.com] > Sent: 24 September 2015 13:29 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [murano] Fix order of arguments in assertEqual > > +1 > > > On 24 Sep 2015, at 10:45, Tetiana Lashchova <tlashch...@mirantis.com> > wrote: > > > > Hi folks! > > > > Some tests in murano code use incorrect order of arguments in > assertEqual. > > The correct order expected by the testtools is > > > > def assertEqual(self, expected, observed, message=''): > > """Assert that 'expected' is equal to 'observed'. > > > > :param expected: The expected value. > > :param observed: The observed value. > > :param message: An optional message to include in the error. > > """ > > > > Error message has the following format: > > > > raise mismatch_error > > testtools.matchers._impl.MismatchError: !=: > > reference = > > actual= > > > > Use of arguments in incorrect order could make debug output very > confusing. > > Let's fix it to make debugging easier. > > > > Best regards, > > Tetiana Lashchova > > __ > > 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 > > __ > Disclaimer: This email and any attachments are sent in strictest confidence > for the sole use of the addressee and may contain legally privileged, > confidential, and proprietary data. If you are not the intended recipient, > please advise the sender by replying promptly to this email and then delete > and destroy this email and any attachments without any further use, copying > or forwarding. > > __ > 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 > -- Best regards, Andrey Kurilin. __ 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] [requirements] why merging 2.6 requirements for non 2.6 supporting projects
Hi! It looks like novaclient still supports py26 :) At least, there is a gate-python-novaclient-python26 job. Also, I checked several commands(boot, *list, delete ) with python 2.6 env and they work as expected for me. On Tue, Jul 14, 2015 at 2:03 PM, Sean Dague s...@dague.net wrote: I just saw this Nova review come in - https://review.openstack.org/#/c/200908 Why are we merging 2.6 requirements for projects that don't support 2.6? That seems potentially confusing to end users that now think the project does, because there are still references in the code. -Sean -- Sean Dague http://dague.net __ 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 -- Best regards, Andrey Kurilin. __ 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] [tox/pep8] different result between running tox and pep8
Running pep8 ., a lot of pep8 mistkes come out. 1) `pep8 .` checks all files in directory(including build files, envs and etc). 2) `pep8 .` doesn't use tox.ini file, which can contain list of ignored rules. For example, it can looks like: [flake8] ignore = H703 3) Most of OpenStack projects use flake8 instead of pep8 On Fri, Jul 10, 2015 at 6:15 AM, Gareth academicgar...@gmail.com wrote: Hi guys My problem looks simple: Running tox -e pep8, the result says ok, not pep8 mistakes. Running pep8 ., a lot of pep8 mistkes come out. But in your project's tox.ini, there isn't such a long ignore list. So what makes this difference happen? Kun __ 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 -- Best regards, Andrey Kurilin. __ 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] [api][nova][ironic] Microversion API HTTP header
Why does alternative implementation need to implement all 50 versions? As far as I understand, API side should not support all versions, that is why version info returns min and max versions https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25-L26 On Tue, Jun 16, 2015 at 11:36 AM, Alex Xu sou...@gmail.com wrote: 2015-06-16 5:24 GMT+08:00 Clint Byrum cl...@fewbar.com: Excerpts from Sean Dague's message of 2015-06-15 14:00:43 -0700: On 06/15/2015 04:50 PM, Jim Rollenhagen wrote: On Mon, Jun 15, 2015 at 01:07:39PM -0400, Jay Pipes wrote: It has come to my attention in [1] that the microversion spec for Nova [2] and Ironic [3] have used the project name -- i.e. Nova and Ironic -- instead of the name of the API -- i.e. OpenStack Compute and OpenStack Bare Metal -- in the HTTP header that a client passes to indicate a preference for or knowledge of a particular API microversion. The original spec said that the HTTP header should contain the name of the service type returned by the Keystone service catalog (which is also the official name of the REST API). I don't understand why the spec was changed retroactively and why Nova has been changed to return X-OpenStack-Nova-API-Version instead of X-OpenStack-Compute-API-Version HTTP headers [4]. To be blunt, Nova is the *implementation* of the OpenStack Compute API. Ironic is the *implementation* of the OpenStack BareMetal API. While I tend to agree in principle, do we reasonably expect that other implementations of these APIs will implement every one of these versions? Can we even reasonably expect another implementation of these APIs? // jim Yeh, honestly, I'm not really convinced that thinking we are doing this for alternative implementations is really the right approach (or even desireable). Honestly, the transition to microversions makes alternative implementations harder because there isn't a big frozen API for a long period of time. Actually that makes an alternative implementation more valuable. Without microversions those alternative implementations would have to wait a long time to implement fixes to the API, but now can implement and publish the fix as soon as the microversion lands. This means that alternative implementations will lag _less_ behind the primary. So if our min_version is 2.1 and the max_version is 2.50. That means alternative implementations need implement all the 50 versions api...that sounds pain... __ 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 -- Best regards, Andrey Kurilin. __ 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][python-novaclient] microversion implementation on client side
There are no so much messages, since first mail was published 2 weeks ago, so I don't want spend a lot of time waiting comments, which may not appear. Btw, some questions appeared in my head related to your suggestions:) When user execute cmd without --os-compute-version. The nova client should discover the nova server supported version. Then cmd choice the latest version supported both by client and server. In that case, why X-Compute-API-Version can accept latest value? Also, such discovery will require extra request to API side for every client call. '--os-compute-version=None' can be supported, that means will return the min version of server supported. From my point of view '--os-compute-version=None' is equal to not specified value. Maybe, it would be better to accept value min for os-compute-version option. The supported version can be discovered by version API (Thanks to Ken'ichi fix this): Yeah. I saw his patch to novaclient, which adds ability to display supported microversions - https://review.openstack.org/#/c/173711/ 3. if the microversion non-supported, but user call cmd with --os-compute-version, this should return failed. Imo, it should be implemented on API side(return BadRequest when X-Compute-API-Version header is presented in V2) On Fri, Apr 24, 2015 at 12:42 PM, Alex Xu sou...@gmail.com wrote: 2015-04-24 17:24 GMT+08:00 Andrey Kurilin akuri...@mirantis.com: Thank you for suggestions! I'll try modify patches as soon as possible. np, it's better waiting for more comment before you begin to update the code first. avoid you need rework again I think :) On Fri, Apr 24, 2015 at 6:56 AM, Alex Xu sou...@gmail.com wrote: Thanks Andrey for hard work on the microverison client support. Wrote down some my thought: I also agreed we will have only one endpoint 'compute'. Hope we can switch v2.1 export as '/v2' in the api-paste.conf as default very soon~ let's say what expected after we only have v2.1 in the world first: There are two cases for use nova client. 1. user use nova client command line. I think command line should support version discover. Provide most convenient way let the user try nova. 2. user use nova client as library. user should call the client code to discover the version and decided what version he want to use by himself. For the command line, the behavior can be: When user execute cmd without --os-compute-version. The nova client should discover the nova server supported version. Then cmd choice the latest version supported both by client and server. This is good for us to introduce the new feature to the user. Also user can specified a version he want to by --os-compute-version. '--os-compute-version=None' can be supported, that means will return the min version of server supported. The supported version can be discovered by version API (Thanks to Ken'ichi fix this): GET '/' https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25 But reality is the v2 and v2.1 will existed at same time. So the v2 or v2.1 code both can run under the endpoint 'compute' with url '/v2'. It depend on the admin's deployment. So I think the cmd also can discover whether the api supported microversion under the 'compute' endpoint. This can be discovered by version api also. GET '/v2/' will return the endpoint version info. Then we can check the version and min_version properties to know whether the api support microversion or not. The behavior can be: 1. If the microversion supported, the cmd behavior is same as the description at the top of this mail 2. If the microversion non-supported, user call cmd without --os-compute-version, we use the min version. 3. if the microversion non-supported, but user call cmd with --os-compute-version, this should return failed. Hope those thoughts are helpful. Looks like this need some change in current patchset also :( I know Andrey already pay lot of on this. But if we like this way, I also can give some help on the coding :) Thanks Alex 2015-04-10 19:30 GMT+08:00 Andrey Kurilin akuri...@mirantis.com: Hi all! I working on implementation of support microversions in novaclient. Patches are ready for review, but there is one opened question: what we should do with v2.1 endpoint(computev21 service type)? compute is a default value of service type and keystone returns v2 api endpoint for it(at least in devstack), so version header will be ignored on API side. On the one hand, each deployment can have it's own configuration of service catalog and endpoints, so default value of service type should be strict and support as much deployments as we can. On the other hand, dependency of service type for microversion feature is not good and end-users should not take care about choice of correct service type when they want to execute simple command. Possible solutions: 1. leave everything as is: use --service-type
Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side
Thank you for suggestions! I'll try modify patches as soon as possible. On Fri, Apr 24, 2015 at 6:56 AM, Alex Xu sou...@gmail.com wrote: Thanks Andrey for hard work on the microverison client support. Wrote down some my thought: I also agreed we will have only one endpoint 'compute'. Hope we can switch v2.1 export as '/v2' in the api-paste.conf as default very soon~ let's say what expected after we only have v2.1 in the world first: There are two cases for use nova client. 1. user use nova client command line. I think command line should support version discover. Provide most convenient way let the user try nova. 2. user use nova client as library. user should call the client code to discover the version and decided what version he want to use by himself. For the command line, the behavior can be: When user execute cmd without --os-compute-version. The nova client should discover the nova server supported version. Then cmd choice the latest version supported both by client and server. This is good for us to introduce the new feature to the user. Also user can specified a version he want to by --os-compute-version. '--os-compute-version=None' can be supported, that means will return the min version of server supported. The supported version can be discovered by version API (Thanks to Ken'ichi fix this): GET '/' https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25 But reality is the v2 and v2.1 will existed at same time. So the v2 or v2.1 code both can run under the endpoint 'compute' with url '/v2'. It depend on the admin's deployment. So I think the cmd also can discover whether the api supported microversion under the 'compute' endpoint. This can be discovered by version api also. GET '/v2/' will return the endpoint version info. Then we can check the version and min_version properties to know whether the api support microversion or not. The behavior can be: 1. If the microversion supported, the cmd behavior is same as the description at the top of this mail 2. If the microversion non-supported, user call cmd without --os-compute-version, we use the min version. 3. if the microversion non-supported, but user call cmd with --os-compute-version, this should return failed. Hope those thoughts are helpful. Looks like this need some change in current patchset also :( I know Andrey already pay lot of on this. But if we like this way, I also can give some help on the coding :) Thanks Alex 2015-04-10 19:30 GMT+08:00 Andrey Kurilin akuri...@mirantis.com: Hi all! I working on implementation of support microversions in novaclient. Patches are ready for review, but there is one opened question: what we should do with v2.1 endpoint(computev21 service type)? compute is a default value of service type and keystone returns v2 api endpoint for it(at least in devstack), so version header will be ignored on API side. On the one hand, each deployment can have it's own configuration of service catalog and endpoints, so default value of service type should be strict and support as much deployments as we can. On the other hand, dependency of service type for microversion feature is not good and end-users should not take care about choice of correct service type when they want to execute simple command. Possible solutions: 1. leave everything as is: use --service-type computev21 for each microversioned command 2. move default value of service type to environment variables(default value is hardcoded in novaclient code now) 3. add additional option --compute-api-type. Proposed etherpad by Christopher Yeoh https://etherpad.openstack.org/p/novaclient_microversions_design . Implementation is already finished - https://review.openstack.org/#/c/167577/ . This proposal still requires addition cli option, but compute-api-type looks more user-friendly Current implementation uses compute as default value for service type. Patches are pass all gates, except stable branches and ready for review: - https://review.openstack.org/#/c/169378/ - deprecate v1.1 and remove references to v3 in code - https://review.openstack.org/#/c/152569/ - Implements 'microversions' api type - Part 1 (usage of nova.api.openstack.api_version_request:APIVersionRequest class with https://review.openstack.org/#/c/169292/ ) - https://review.openstack.org/#/c/167408/ - Implements 'microversions' api type - Part 2 (adds new decorators and substitution mechanism using nova.api.openstack.versioned_method ) - https://review.openstack.org/#/c/136458/ - Implementation of 2.2 microversion -- Best regards, Andrey Kurilin. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http
Re: [openstack-dev] [opentack-dev][meetings] Proposing changes in Rally meetings
- We should start making agenda for each meeting and publish it to Rally wiki +1 * Second is release management meeting, where we are discussing priorities for current next release. So core team will know what to review first. It would be nice to post list of high priority patches to etherpad or google docs after each meeting - Move meetings from #openstack-meeting to #openstack-rally chat. doesn't matter for me:) - We should adjust better time for current Rally team. yeah. Current time is not good:( +1 for 15:00 UTC - Do meetings every Monday and Wednesday Monday?) Monday is very hard day... On Fri, Apr 17, 2015 at 4:26 PM, Boris Pavlovic bo...@pavlovic.me wrote: Rally team, I would like to propose next changes in Rally meetings: - We should start making agenda for each meeting and publish it to Rally wiki - We should do 2 meeting per week: * First is regular meeting (like we have now) where we are discussing everything * Second is release management meeting, where we are discussing priorities for current next release. So core team will know what to review first. - Move meetings from #openstack-meeting to #openstack-rally chat. - We should adjust better time for current Rally team. Like at the moment it is too late for few of cores in Rally. it's 17:00 UTC and I would like to suggest to make at 15:00 UTC. - Do meetings every Monday and Wednesday Thoughts ? Best regards, Boris Pavlovic -- Best regards, Andrey Kurilin. __ 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] novaclient 'stable-compat-jobs-{name}' broken
Given that, is it okay if I propose a patch to remove the
'stable-compat-jobs-{name}' build jobs for python-novaclient in
project-config?
I suppose we should remove 'stable-compat-jobs-{name}', since novaclient is
already blocked for one week and it looks like there are no another
solutions for now.
On Fri, Apr 10, 2015 at 8:02 AM, melanie witt melwi...@gmail.com wrote:
Hi all,
The following 'stable-compat-jobs-{name}' build jobs have been broken the
past two days, blocking all novaclient patches from passing jenkins checks:
gate-tempest-dsvm-neutron-src-python-novaclient-icehouse
gate-tempest-dsvm-neutron-src-python-novaclient-juno
The original purpose of these jobs was to check that patches proposed to
master wouldn't break in stable branches. This was before we started
pinning novaclient versions on stable branches. Now that we've pinned, the
way these jobs were passing was by installing the current novaclient, then
uninstalling it, then installing a version from pypi that fits within the
global requirements for the branch in question (icehouse or juno), then
running the tests.
Well, recently this stopped working because for some reason, devstack is
no longer able to uninstall the latest version:
Found existing installation: python-novaclient 2.23.0.post14
Can't uninstall 'python-novaclient'. No files were found to uninstall.
And then I see the following error as a result:
pkg_resources.ContextualVersionConflict: (python-novaclient 2.23.0.post14
(/opt/stack/new/python-novaclient),
Requirement.parse('python-novaclient=2.20.0,=2.18.0'),
set(['ceilometer']))
I asked about this in #openstack-infra and was told we really shouldn't be
running the src build jobs on patches proposed to master anyhow, and that
it's not the right flow for devstack to install the latest, then uninstall
it, then install an older global reqs compatible version anyway.
Given that, is it okay if I propose a patch to remove the
'stable-compat-jobs-{name}' build jobs for python-novaclient in
project-config?
Then after that, how are we supposed to go about cutting stable branches
for novaclient? And how can we get the 'stable-compat-jobs-{name}' jobs
running on only those respective branches? In project-config I didn't
understand how to limit build jobs to only patches proposed to a stable
branch.
I'd appreciate any insights.
Thanks,
melanie (melwitt)
__
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
--
Best regards,
Andrey Kurilin.
__
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-operators] [all][qa][gabbi][rally][tempest] Extend rally verfiy to unify work with Gabbi, Tempest and all in-tree functional tests
I have an alternative solution for `rally verify project start` command.
What do you think about similar management stuff for verifiers as we have
for deployments?
It requires several changes:
- `rally verifiers` command: Implementation of new command, which will
manage(install, reinstall, remove, configure) verifiers(tempest,
project-specific functional tests, gabbi and etc), will allow users to have
several tempest verifiers with different configurations or branches and
easily switch between them.
- `rally verify` command: The original verification command will check
selected verifier and contain only verifier-specific sub-commands.
- db changes: we will need to store information about verifiers
On Thu, Mar 12, 2015 at 2:33 AM, Boris Pavlovic bo...@pavlovic.me wrote:
Alex,
* rally plugin should be a part of project (for example, located in
functional tests directory)
There are 2 issues with such solution:
1) If rally didn't load plugin, command rally verify project won't
exist
2) Putting some strange Rally plugin to source of other projects will be
quite complicated task.
I believe we should have at least POC before even asking for such
stuff.
* use {project url} instead of {project name} in rally verify command,
example:
I agree here with Andrey, it is bad UX. Forcing people to write every time
URLs is terrible.
They will build own tools on top of such solution.
What about rally verify nova start --url where --url is optional
argument?
If --url is not specified default url is used.
Best regards,
Boris Pavlovic
On Wed, Mar 11, 2015 at 7:14 PM, Andrey Kurilin akuri...@mirantis.com
wrote:
$ rally verify https://github.com/openstack/nova start
As one of end-users of Rally, I dislike such construction, because I
don't want to remember links to repos, they are too long for me:)
On Wed, Mar 11, 2015 at 12:49 PM, Aleksandr Maretskiy
amarets...@mirantis.com wrote:
The idea is great, but IMHO we can move all project-specific code out of
rally, so:
* rally plugin should be a part of project (for example, located in
functional tests directory)
* use {project url} instead of {project name} in rally verify command,
example:
$ rally verify https://github.com/openstack/nova start
On Tue, Mar 10, 2015 at 6:01 PM, Timur Nurlygayanov
tnurlygaya...@mirantis.com wrote:
Hi,
I like this idea, we use Rally for OpenStack clouds verification at
scale and it is the real issue - how to run all functional tests from each
project with the one script. If Rally will do this, I will use Rally to run
these tests.
Thank you!
On Mon, Mar 9, 2015 at 6:04 PM, Chris Dent chd...@redhat.com wrote:
On Mon, 9 Mar 2015, Davanum Srinivas wrote:
2. Is there a test project with Gabbi based tests that you know of?
In addition to the ceilometer tests that Boris pointed out gnocchi
is using it as well:
https://github.com/stackforge/gnocchi/tree/master/gnocchi/
tests/gabbi
3. What changes if any are needed in Gabbi to make this happen?
I was unable to tell from the original what this is and how gabbi
is involved but the above link ought to be able to show you how
gabbi can be used. There's also the docs (which could do with some
improvement, so suggestions or pull requests welcome):
http://gabbi.readthedocs.org/en/latest/
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
__
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
--
Timur,
Senior QA Engineer
OpenStack Projects
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
--
Best regards,
Andrey Kurilin.
__
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
