Re: [openstack-dev] [all][tc][ptls] final stages of python 3 transition
Hi Doug, There is no ec2-api project on the link. But we have voted job openstack-tox-py35 <http://logs.openstack.org/85/552085/2/check/openstack-tox-py35/6464ed8/> Regards, Andrey Pavlov. On Mon, Apr 30, 2018 at 6:06 PM, Doug Hellmann <d...@doughellmann.com> wrote: > It would be useful to have more input from PTLs on this issue, so I'm > CCing all of them to get their attention. > > Excerpts from Doug Hellmann's message of 2018-04-25 16:54:46 -0400: > > It's time to talk about the next steps in our migration from python > > 2 to python 3. > > > > Up to this point we have mostly focused on reaching a state where > > we support both versions of the language. We are not quite there > > with all projects, as you can see by reviewing the test coverage > > status information at > > https://wiki.openstack.org/wiki/Python3#Python_3_Status_ > of_OpenStack_projects > > > > Still, we need to press on to the next phase of the migration, which > > I have been calling "Python 3 first". This is where we use python > > 3 as the default, for everything, and set up the exceptions we need > > for anything that still requires python 2. > > > > To reach that stage, we need to: > > > > 1. Change the documentation and release notes jobs to use python 3. > >(The Oslo team recently completed this, and found that we did > >need to make a few small code changes to get them to work.) > > 2. Change (or duplicate) all functional test jobs to run under > >python 3. > > 3. Change the packaging jobs to use python 3. > > 4. Update devstack to use 3 by default and require setting a flag to > >use 2. (This may trigger other job changes.) > > > > At that point, all of our deliverables will be produced using python > > 3, and we can be relatively confident that if we no longer had > > access to python 2 we could still continue operating. We could also > > start updating deployment tools to use either python 3 or 2, so > > that users could actually deploy using the python 3 versions of > > services. > > > > Somewhere in that time frame our third-party CI systems will need > > to ensure they have python 3 support as well. > > > > After the "Python 3 first" phase is completed we should release > > one series using the packages built with python 3. Perhaps Stein? > > Or is that too ambitious? > > > > Next, we will be ready to address the prerequisites for "Python 3 > > only," which will allow us to drop Python 2 support. > > > > We need to wait to drop python 2 support as a community, rather > > than going one project at a time, to avoid doubling the work of > > downstream consumers such as distros and independent deployers. We > > don't want them to have to package all (or even a large number) of > > the dependencies of OpenStack twice because they have to install > > some services running under python 2 and others under 3. Ideally > > they would be able to upgrade all of the services on a node together > > as part of their transition to the new version, without ending up > > with a python 2 version of a dependency along side a python 3 version > > of the same package. > > > > The remaining items could be fixed earlier, but this is the point > > at which they would block us: > > > > 1. Fix oslo.service functional tests -- the Oslo team needs help > >maintaining this library. Alternatively, we could move all > >services to use cotyledon (https://pypi.org/project/cotyledon/). > > > > 2. Finish the unit test and functional test ports so that all of > >our tests can run under python 3 (this implies that the services > >all run under python 3, so there is no more porting to do). > > > > Finally, after we have *all* tests running on python 3, we can > > safely drop python 2. > > > > We have previously discussed the end of the T cycle as the point > > at which we would have all of those tests running, and if that holds > > true we could reasonably drop python 2 during the beginning of the > > U cycle, in late 2019 and before the 2020 cut-off point when upstream > > python 2 support will be dropped. > > > > I need some info from the deployment tool teams to understand whether > > they would be ready to take the plunge during T or U and start > > deploying only the python 3 version. Are there other upgrade issues > > that need to be addressed to support moving from 2 to 3? Something > > that might be part of the platform(s), rather than OpenStack itself? > > > > What else have I missed in these phases? Other jobs? Other blocking > > conditions? > > > > Doug > __ OpenStack Development Mailing 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][dragonflow][ec2-api][PowerVMStackers][murano] Tagging rights
Hello Sean, EC2-api team always used manual tagging because I know only this procedure. I thought that it's more convenient for me cause I can manage commits/branches. But in fact I don't mind to switch to automatic scheme. If somethig else is needed from please let me know. Regards, Andrey Pavlov. > Hello teams, I am following up on some recently announced changes regarding governed projects and tagging rights. See [1] for background. It was mostly followed before that when a project came under official governance that all tagging and releases would then move to using the openstack/releases repo and associated automation. It was not officially stated until recently that this was one of the steps of coming under governance, so there were a few projects that became official but that continued to do their own releases. We've cleaned up most projects' rights to push tags, but for the ones listed here we waited: - rally - dragflow - ec2-api - networking-powervm - nova-powervm - yaql We would like to finish cleaning up the ACLs for these, but I wanted to check with the teams to make sure there wasn't a reason why these repos had continued tagging separately. Please let me know, either here or in the #openstack-release channel, if there is something we are overlooking. Thanks for your attention. --- Sean (smcginnis) __ OpenStack Development Mailing 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] more help needed
Hi Matthew, stable/queens has been created for ec2-api project. project gce-api is mostly dead. Regards, Andrey Pavlov. __ OpenStack Development Mailing 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][ec2-api] How about using boto3 instead of boto in requirements
Hi, We (ec2-api team) now in the middle of some investigations that should lead us to either to remove boto from the code or to change it to botocore as we decided previously. We'll done with it to the middle of July. Regards, Andrey Pavlov. On Tue, Jun 20, 2017 at 10:15 AM, Tony Breeds <t...@bakeyournoodle.com> wrote: > On Mon, Jun 19, 2017 at 09:33:02PM +0800, jiaopengju wrote: > > Hi Dims, > > I got response from core member of ec2-api. What do you think about it? > > > > > > -- > > Hi, > > > > > > I don't treat adding new library as a problem. > > > > > > - I see that you don't remove boto - so your change doesn't affect > ec2-api code. > > Part of the role of the requirements team is to ensure that we don't end > up with several libraries that have significant overlap in > functionality. Clearly boto and boto3 fall squarely in that camp. > > What the requirements team needs is some assurance that switching to > boto3 is something that the ec2-api team would be able to do. Running > on boto which has been deprecated in favor of boto3 make sense from a > lot of levels. We're far enough into the Queens cycle that I doubt it'd > happen this cycle :( > > 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
Re: [openstack-dev] [glance] priorities for the coming week (12/09-12/15)
Hello, Can you also review this - https://review.openstack.org/#/c/401277/ for bug - https://bugs.launchpad.net/glance-store/+bug/1644177 And please consider backport to Newton. This bug is very annoying for deployments with several controllers and glance over cinder... On Fri, Dec 9, 2016 at 3:14 PM, Brian Rosmaita <rosmaita.foss...@gmail.com> wrote: > As discussed at the Glance weekly meeting yesterday, the priorities for > 12/1 through 12/8, unfortunately look very similar to last week's > priorities. Some core reviewers need to step up. The priorities are: > > Highest priority > > > (1) database strategy for rolling upgrades: > https://review.openstack.org/#/c/331740/ > This one has a video to enhance your reviewing pleasure and demonstrate > that the approach described actually is workable: > https://www.youtube.com/watch?v=Z4iwJRlPqOw > > (2) glance expand/contract migrations with alembic: > https://review.openstack.org/#/c/374278/ > We need another +2 on this one, preferably from a non-Rackspace person. > > (3) community images spec update: > https://review.openstack.org/#/c/396919/ > New to the list. The latest patch includes the migration strategy for > which Erno said indicated on the patch he'd change his -2 to a +2, so > don't let the -2 on the patch stop you from reviewing it. > > The above three specs need to be reviewed as soon as possible. We are > blocking Alex and Hemanth, because the Ocata database migration will > handle the community images changes. > > > Really high priority > > (would be highest if the specs were already approved) > > (4) Patch to fix a glance_store regression: > https://review.openstack.org/#/c/387719/ > and patch to prevent a related backend misconfiguration: > https://review.openstack.org/#/c/388944/ > > (5) Patch to enable better request-id tracking: > https://review.openstack.org/#/c/352892/ > This will be nice for operators, let's get it reviewed and merged! > > (6) Request for some insights and opinions for bug > https://bugs.launchpad.net/glance/+bug/1585917 > > > Please take a look > == > > (7) glanceclient problem: https://review.openstack.org/#/c/319960/ > > thanks, > brian > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kind Regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [charms] Deploy Keystone To Public Cloud
Yeah, I had the same situation in Juju 2.0 ! (all is ok with Juju 1.25) (with AWS provider) It happens because OpenStack charms started to use 'network-get --primary-address public' instead of 'unit-get'. Then 'network-get public' returns private address and then charms register endpoint with private address and then they do not work from outside. I could solve this only be setting 'os-public-hostname' to floating-ip of specific machine. On Thu, Nov 17, 2016 at 2:14 AM, James Beedy <jamesbe...@gmail.com> wrote: > I'm having an issue getting a response back (mostly timeouts occur) when > trying to talk to keystone deployed to AWS using private (on vpn) or public > ip address. I've had luck with setting os-*-hostname configs, and ssh'ing > in and running the keystone/openstack client locally from the keystone > instance after adding the private ip <-> fqdn mapping in > keystone:/etc/hosts, but can't seem to come up with any combination that > lets me talk to the keystone api remotely. Just to be clear, I'm only > deploying keystone and percona-cluster charms to AWS, not all of Openstack. > > If not possible using the ec2 provider, is this a possibility with any > public providers? > > Thanks > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [stable] Bug backports
Hi, I want to backport this bug - https://bugs.launchpad.net/glance-store/+bug/1616556 but review for master is stuck since August - https://review.openstack.org/#/c/357827/ On Mon, Oct 10, 2016 at 4:05 PM, Ian Cordasco <sigmaviru...@gmail.com> wrote: > -Original Message- > From: Ian Cordasco <sigmaviru...@gmail.com> > Reply: Ian Cordasco <sigmaviru...@gmail.com> > Date: October 7, 2016 at 08:47:19 > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: [Glance] [stable] Bug backports > > > Hi Glancers! > > > > After the news that we all released Newton yesterday, it's time to start > thinking about > > backports the future of our Mitaka and Liberty branches. > > > > I expect that Mitaka will start to enter Phase II [1] and Liberty's > end-of-life is right > > around the corner [2] (2016-11-17). If there are bugs that are affecting > those branches > > that need to be backported before their status changes, they should be > proposed immediately > > and brought up at the Glance team meeting [3]. > > > > [1]: http://docs.openstack.org/project-team-guide/stable-branches.html > > [2]: https://releases.openstack.org/ > > [3]: http://eavesdrop.openstack.org/#Glance_Team_Meeting > > > In case you missed it, Friday the 14th (October 2016) the stable team > is moving Mitaka to Phase II and Liberty to Phase III [1]. > > Please respond to this message with bugs and backport reviews that > should land prior to Mitaka entering Phase II. > > [1]: http://lists.openstack.org/pipermail/openstack-dev/ > 2016-October/105302.html > > Cheers, > -- > 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 > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] iscsi backend for glance and cinder.
Try to use cinder as backend for glance. It works from Mitaka. Regards, Andrey. On Wed, Oct 5, 2016 at 6:03 AM, 박준하 <pj...@kinx.net> wrote: > Hello, > > I’m now planning to use Netapp storage with iscsi mode as volume > storage(Cinder) and image storage(Glance) > > > > There is a problem that I want to use Netapp storage for Glance Backeds > with iscsi, I mean, I don’t want to use Netapp as NFS, but I could not find > any guides about setting glance’s backends on iscsi. Could you guys have > any idea about it? > > > > Regards, > > Jun-ha Park > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] Is there any reason we shouldn't remove nova.image.s3 now?
I've tried to do it some time ago - https://review.openstack.org/#/c/266425/ But I tried to remove more than s3_image But there was no consensus... Regards, Andrey. On Thu, Sep 22, 2016 at 3:01 PM, Sean Dague <s...@dague.net> wrote: > On 09/22/2016 02:53 AM, Clint Byrum wrote: > > Excerpts from Matt Riedemann's message of 2016-09-21 18:43:06 -0500: > >> The s3 image configuration options were deprecated for removal in newton > >> [1]. > >> > >> Clint has a patch up to remove the boto dependency from nova [2] which > >> is only used in the nova.image.s3 module. > >> > >> Rather than remove the boto dependency, I think we should just remove > >> this code. Is there any reason to not do that now that Ocata is open and > >> it's been over the requisite 3 month window of deprecation for CD shops? > >> > >> [1] https://review.openstack.org/#/c/314697/ > >> [2] https://review.openstack.org/#/c/374433/ > >> > > > > I went ahead and updated this review to remove the code. This is > > definitely cleaner, and users of it can certainly resurrect it out of > > tree if they are in need of it. > > +1 on the drop, but we should make sure to pull the related code in the > process. I left notes in the review for other things that can go. > > The one open question to me, we've got a dedicated db table for > s3_images. Which, I have no idea when it was last used for anything. > What kind of warning do we need to do on a full table drop? Do we need > to handle the independently? > > -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 > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] Upcoming OpenStackClient 3.0 Release (Monday)
ng hard on the Networking commands. > > 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 > > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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 module has been deleted even if it is consumed by the project?
ec2-api (and gce-api) already has this job, so I just add them to projects.txt, right? https://review.openstack.org/#/c/354899/ and after this will be merged I can revert botocore requirement to global-requirements, right? On Fri, Aug 12, 2016 at 6:21 PM, Matthew Thode <prometheanf...@gentoo.org> wrote: > On 08/12/2016 09:53 AM, Andrey Pavlov wrote: > > Thanks for the answer, > > > > I don't know why - but requirements job is not in the list of jobs. It > > present only in comment from jenkins. > > Logs are here > > - http://logs.openstack.org/67/354667/1/check/gate-ec2-api- > requirements/4e9e1da/ > > > > And I would like to include ec2api project > > to openstack/requirements/projects.txt > > Is it possible? > > Ya, you can you'll first need to add the check-requirements job to your > list of test in project-config. Once it's added there we can add your > project to projects.txt > > The relevant section of the readme is here. > > https://github.com/openstack/requirements/#enforcement-in-projects > > -- > -- Matthew Thode (prometheanfire) > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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 module has been deleted even if it is consumed by the project?
Thanks for the answer, I don't know why - but requirements job is not in the list of jobs. It present only in comment from jenkins. Logs are here - http://logs.openstack.org/67/354667/1/check/gate-ec2-api-requirements/4e9e1da/ And I would like to include ec2api project to openstack/requirements/ projects.txt Is it possible? On Fri, Aug 12, 2016 at 5:42 PM, Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from Andrey Pavlov's message of 2016-08-12 16:50:21 +0300: > > Hi, > > > > When I've tried to bump version in ec2api project for some library - I've > > got an error from requirements-gate job [1]. > > I've investigated this issue and found that this module was deleted from > > global requirements with comment 'only ec2api is using it'. > > It was done in the review [2]. > > > > What happens? > > Why consumed module was deleted? > > How I can update this requirement now? > > What means phrase "This is not consumed by any projects managed by > > requirements."? > > > > > > [1] - https://review.openstack.org/#/c/354667/ > > [2] - https://review.openstack.org/#/c/321955/ > > > > It looks like you're trying to change the version of botocore used by > the ec2-api project. Is that right? > > I don't see the requirements gate job in the list of tests that ran > against patch [1] at all, so I'm not sure where the error message > you reported is coming from. Can you link to a log from the job? > > I don't see ec2-api listed in openstack/requirements/projects.txt > as a project that receives automated updates from the global > requirements list. Looking through all of the requirements files > for all projects, I get: > > ec2-api requirements.txt botocore>=1.0.0 > rpm-packaging global-requirements.txtbotocore>=1.0.0 > > Because only projects that aren't syncing requirements were using > botocore, it didn't need to be included in the list of global > requirements that is synced with projects. You should be able to > modify your requirements list directly to update to the newer > version. > > Doug > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [requirements] Why module has been deleted even if it is consumed by the project?
Hi, When I've tried to bump version in ec2api project for some library - I've got an error from requirements-gate job [1]. I've investigated this issue and found that this module was deleted from global requirements with comment 'only ec2api is using it'. It was done in the review [2]. What happens? Why consumed module was deleted? How I can update this requirement now? What means phrase "This is not consumed by any projects managed by requirements."? [1] - https://review.openstack.org/#/c/354667/ [2] - https://review.openstack.org/#/c/321955/ -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [juju charms] How to configure glance charm for specific cnider backend?
Hi, Maybe I understood this option - Instead of adding one more relation to glance, I can relate my charm to new relation 'cinder-volume-service' So there is no more changes in the glance charm. And additional in my charm will be - metadata.yaml - *subordinate: trueprovides: image-backend:interface: cinderscope: container* and then I can relate my charm to glance (and my charm will be installed in the same container as glance, so I can configure OS) *juju add-relation glance:cinder-volume-service scaleio-openstack:image-backend* This option works for me - I don't need to add something to glance config. I'm only need to add files to /etc/glance/rootwrap.d/ and this option allows to do it. I've made additional review - https://review.openstack.org/#/c/350565/ But I don't need it :) Should I abandon it or not? On Tue, Aug 2, 2016 at 6:15 PM, James Page <james.p...@ubuntu.com> wrote: > Hi Andrey > > On Tue, 2 Aug 2016 at 15:59 Andrey Pavlov <andrey...@gmail.com> wrote: > >> I need to add glance support via storing images in cinder instead of >> local files. >> (This works only from Mitaka version due to glance-store package) >> > > OK > > >> First step I've made here - >> https://review.openstack.org/#/c/348336/ >> This patchset adds ability to relate glance-charm to cinder-charm >> (it's similar to ceph/swift relations) >> > > Looks like a good start, I'll comment directly on the review with any > specific comments. > > >> And also it configures glance's rootwrap - original glance package >> doesn't have such code >> ( >> I think that this is a bug in glance-common package - cinder and >> nova can do it themselves. >> And if someone point me to bugtracker - I will file the bug there. >> ) >> > > Sounds like this should be in the glance package: > > https://bugs.launchpad.net/ubuntu/+source/glance/+filebug > > or use: > > ubuntu-bug glance-common > > on an installed system. > > >> But main question is about additional configurations' steps - >> Some cinder backends need to store additional files in >> /etc/glance/rootwrap.d/ folder. >> I have two options to implement this - >> 1) relate my charm to glance:juju-info (it will be run on the same >> machine as glance) >> and do all work in this hook in my charm. >> 2) add one more relation to glance - like >> 'storage-backend:cinder-backend' in cinder. >> And write code in a same way - with ability to pass config options. >> > >> I prefer option 2. It's more logical and more general. It will allow >> to configure any cinder's backend. >> > > +1 the subordinate approach in cinder (and nova) works well; lets ensure > the semantics on the relation data mean its easy to restart the glance > services from the subordinate service if need be. > > Taking this a step further, it might also make sense to have the relation > to cinder on the subordinate charm and pass up the data item to configure > glance to use cinder from the sub - does that make sense in this context? > > Cheers > > James > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [juju charms] How to configure glance charm for specific cnider backend?
James, thank you for your answer. I'll file bug to glance - but in current releases glance-charm have to do it himself, right? I'm not sure that I'm correctly understand your question. I suppose that deployment will have glance and cinder on different machines. Also there will be one relation between cinder and glance to configure glance to store images in cinder. Other steps are optional - If cinder is used specific backend that needs additional configuration - then it can be done via storage-backend relation (from subordinate charm). If this backend needs to configure glances' filters or glance's config - then it should be done via any subordinate charm to glance (but glance doesn't have such relations now). Due to these suggestions I think that additional relation needs to be added to glance to allow connecting charms (with installation in the same container as glance). On Tue, Aug 2, 2016 at 6:15 PM, James Page <james.p...@ubuntu.com> wrote: > Hi Andrey > > On Tue, 2 Aug 2016 at 15:59 Andrey Pavlov <andrey...@gmail.com> wrote: >> >> I need to add glance support via storing images in cinder instead of >> local files. >> (This works only from Mitaka version due to glance-store package) > > > OK > >> >> First step I've made here - >> https://review.openstack.org/#/c/348336/ >> This patchset adds ability to relate glance-charm to cinder-charm >> (it's similar to ceph/swift relations) > > > Looks like a good start, I'll comment directly on the review with any > specific comments. > >> >> And also it configures glance's rootwrap - original glance package >> doesn't have such code >> ( >> I think that this is a bug in glance-common package - cinder and >> nova can do it themselves. >> And if someone point me to bugtracker - I will file the bug there. >> ) > > > Sounds like this should be in the glance package: > > https://bugs.launchpad.net/ubuntu/+source/glance/+filebug > > or use: > > ubuntu-bug glance-common > > on an installed system. > >> >> But main question is about additional configurations' steps - >> Some cinder backends need to store additional files in >> /etc/glance/rootwrap.d/ folder. >> I have two options to implement this - >> 1) relate my charm to glance:juju-info (it will be run on the same >> machine as glance) >> and do all work in this hook in my charm. >> 2) add one more relation to glance - like >> 'storage-backend:cinder-backend' in cinder. >> And write code in a same way - with ability to pass config options. >> >> >> I prefer option 2. It's more logical and more general. It will allow >> to configure any cinder's backend. > > > +1 the subordinate approach in cinder (and nova) works well; lets ensure the > semantics on the relation data mean its easy to restart the glance services > from the subordinate service if need be. > > Taking this a step further, it might also make sense to have the relation to > cinder on the subordinate charm and pass up the data item to configure > glance to use cinder from the sub - does that make sense in this context? > > Cheers > > James > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [juju charms] How to configure glance charm for specific cnider backend?
Hi All, I need to add glance support via storing images in cinder instead of local files. (This works only from Mitaka version due to glance-store package) First step I've made here - https://review.openstack.org/#/c/348336/ This patchset adds ability to relate glance-charm to cinder-charm (it's similar to ceph/swift relations) And also it configures glance's rootwrap - original glance package doesn't have such code ( I think that this is a bug in glance-common package - cinder and nova can do it themselves. And if someone point me to bugtracker - I will file the bug there. ) But main question is about additional configurations' steps - Some cinder backends need to store additional files in /etc/glance/rootwrap.d/ folder. I have two options to implement this - 1) relate my charm to glance:juju-info (it will be run on the same machine as glance) and do all work in this hook in my charm. 2) add one more relation to glance - like 'storage-backend:cinder-backend' in cinder. And write code in a same way - with ability to pass config options. I prefer option 2. It's more logical and more general. It will allow to configure any cinder's backend. But I prefer to know community opinion before I start to implement this. -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [devstack] How to enable SSL in devStack?
Hi, When I ran devstack with SSL I found a bug and tried to fix it - https://review.openstack.org/#/c/242812/ But no one agree with me. Try to apply this patch - it may help. Also there is a chance that new bugs present in devstack that prevented to install it with SSL. Regards, Andrey. On Wed, Jul 20, 2016 at 4:38 AM, Wenzhi Yu (yuywz) <wenzhi...@163.com> wrote: > Thanks for your reply, Andrey. I tried set USE_SSL=True but still got the > same error: > > 2016-07-20 01:29:21.446 | Discovering versions from the identity service > failed when creating the password plugin. Attempting to determine version > from URL. > 2016-07-20 01:29:21.446 | Could not determine a suitable URL for the plugin. > > Please see the detailed log here: http://paste.openstack.org/show/538761/ > Here is my local.conf: http://paste.openstack.org/show/538762/ > 2016-07-20 > > Best Regards, > Wenzhi Yu (yuywz) > ____ > 发件人：Andrey Pavlov <andrey...@gmail.com> > 发送时间：2016-07-19 16:46 > 主题：Re: [openstack-dev] [devstack] How to enable SSL in devStack? > 收件人："OpenStack Development Mailing List (not for usage > questions)"<openstack-dev@lists.openstack.org> > 抄送： > > just add > > USE_SSL=True > > to your localrc before run stack.sh > > Regards, > Andrey. > > On Tue, Jul 19, 2016 at 10:17 AM, Wenzhi Yu (yuywz) <wenzhi...@163.com> > wrote: >> Hi folks, >> >> I want to configure the openstack endpoints to use SSL in devStack. >> >> I searched on internet and found some posts like [1] and tried the >> configuration in the post, but devStack script failed with error messages >> like: >> "Discovering versions from the identity service failed when creating the >> password plugin. Attempting to determine version from URL. Could not >> determine a suitable URL for the plugin." >> [1]https://ask.openstack.org/en/question/45348/devstack-with-ssl/ >> >> So how to enable SSL in devStack? Can anyone please give me some guidance? >> Thanks! >> >> 2016-07-19 >> >> Best Regards, >> Wenzhi Yu (yuywz) >> >> ______ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Kind regards, > Andrey Pavlov. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [devstack] How to enable SSL in devStack?
just add USE_SSL=True to your localrc before run stack.sh Regards, Andrey. On Tue, Jul 19, 2016 at 10:17 AM, Wenzhi Yu (yuywz) <wenzhi...@163.com> wrote: > Hi folks, > > I want to configure the openstack endpoints to use SSL in devStack. > > I searched on internet and found some posts like [1] and tried the > configuration in the post, but devStack script failed with error messages > like: > "Discovering versions from the identity service failed when creating the > password plugin. Attempting to determine version from URL. Could not > determine a suitable URL for the plugin." > [1]https://ask.openstack.org/en/question/45348/devstack-with-ssl/ > > So how to enable SSL in devStack? Can anyone please give me some guidance? > Thanks! > > 2016-07-19 > > Best Regards, > Wenzhi Yu (yuywz) > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [charms] Re-licensing OpenStack charms under Apache 2.0
Hello James, No problem on my side. Regards, Andrey. On Wed, Jun 8, 2016 at 1:20 PM, James Page <james.p...@ubuntu.com> wrote: > Hi > > We're currently blocked on becoming an OpenStack project under the big-tent > by the licensing of the 26 OpenStack charms under GPL v3. > > I'm proposing that we re-license the following code repositories as Apache > 2.0: > > charm-ceilometer > charm-ceilometer-agent > charm-ceph > charm-ceph-mon > charm-ceph-osd > charm-ceph-radosgw > charm-cinder > charm-cinder-backup > charm-cinder-ceph > charm-glance > charm-hacluster > charm-heat > charm-keystone > charm-lxd > charm-neutron-api > charm-neutron-api-odl > charm-neutron-gateway > charm-neutron-openvswitch > charm-nova-cloud-controller > charm-nova-compute > charm-odl-controller > charm-openstack-dashboard > charm-openvswitch-odl > charm-percona-cluster > charm-rabbitmq-server > charm-swift-proxy > charm-swift-storage > > The majority of contributors are from Canonical (from whom I have permission > to make this switch) with a further 18 contributors from outside of > Canonical who I will be directly contacting for approval in gerrit as > reviews are raised for each repository. > > Any new charms and supporting repositories will be licensed under Apache 2.0 > from the outset. > > Cheers > > James > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [tempest] SSH hangs at the end with channel.closed=False
Hello, I found that sometimes SSH connection can hang when all data is received. It hangs with "channel.closed=False". tempest/lib/common/ssh.py line 134 May be some one knows what happened? -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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][ec2-api] What happened with EC2-API project in gerrit?
Thank you Jeremy! On Mon, Mar 28, 2016 at 9:12 PM, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2016-03-28 10:46:27 -0400 (-0400), Davanum Srinivas wrote: >> y, whoa! Andrey, i just pinged folks on #openstack-infra. > > Yes, sorry about that. There's an issue in Gerrit where it can get > confused and believe repos are corrupt when it fails to read Git > objects under some circumstances, and that may have befallen the > ec2-api project. It's the first time we've seen this since the 2.11 > upgrade, as far as I know, and a Gerrit restart was necessary to get > it to start showing up as usable again. If you happen to spot any > seemingly related issues, please let the Infra team know. > -- > 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 -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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][ec2-api] What happened with EC2-API project in gerrit?
Ian, yes. this is one of visible problems... Regards, Andrey. On Mon, Mar 28, 2016 at 5:39 PM, Ian Cordasco <sigmaviru...@gmail.com> wrote: > > > -Original Message- > From: Andrey Pavlov <andrey...@gmail.com> > Reply: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Date: March 28, 2016 at 09:34:54 > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Infra][ec2-api] What happened with EC2-API > project in gerrit? > >> But why I can't see the project in the gerrit.openstack.org? > > I'm not seeing any reviews on Gerrit either: > https://review.openstack.org/#/q/project:openstack/ec2-api+AND+(status:merged+OR+status:open) > > I think this is what you're asking about, right Andrey? > -- > Ian Cordasco > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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][ec2-api] What happened with EC2-API project in gerrit?
But why I can't see the project in the gerrit.openstack.org? On Mon, Mar 28, 2016 at 5:19 PM, Davanum Srinivas <dava...@gmail.com> wrote: > it's there : http://git.openstack.org/cgit/openstack/ec2-api/ > > -- Dims > > On Mon, Mar 28, 2016 at 10:12 AM, Andrey Pavlov <andrey...@gmail.com> wrote: >> Hello, >> >> Today I found that our EC2-API project has disappeared from gerrit... >> Yesterday it was accessible... >> >> It is still present on github.com/openstack/ec2-api >> Configuration is still present in project-config repository. >> I can't find any changes in governance project related to ec2-api project. >> >> Can anyone say me what happened with our EC2-API project? >> >> -- >> Kind regards, >> Andrey Pavlov. >> >> __ >> OpenStack Development Mailing 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 -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [Infra][ec2-api] What happened with EC2-API project in gerrit?
Hello, Today I found that our EC2-API project has disappeared from gerrit... Yesterday it was accessible... It is still present on github.com/openstack/ec2-api Configuration is still present in project-config repository. I can't find any changes in governance project related to ec2-api project. Can anyone say me what happened with our EC2-API project? -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [swift3][swift] What happens in swift3?
It's good that there are concerns about the stability of the current auth process. But... - there are many tests (unit and functional) show that current functionality was not broken. - there are new unit tests specially for sig v4 functionality - i try to commit this patch in current development/testing process. not to stable release. - i made two another patches [1] and [2] to show that all current functional tests are working (with boto patches). I can make one more jenkins job for run functest with sig V4 but [1] (with changes in tox.ini) should be commited first. I'm sorry but it is a first time that I hear about docs "what's changed". What doc do you mean? Also - Where I can describe config changes? (This is only one change and devstack already has a code that configures it.) [1] https://review.openstack.org/#/c/272516 [2] https://review.openstack.org/#/c/285678 Kind Regards, Andrey. On Wed, Mar 16, 2016 at 6:41 AM, Kota TSUYUZAKI <tsuyuzaki.k...@lab.ntt.co.jp> wrote: > Tim is sill working for making sure how the sigv4 patch works[1]. The couple > of main reasons for the slow review is, right now, no way to make sure the > sigv4 in functests for jenkins job and no docs > about what's changed, what's constraint, what's we should change our config > in those patches. In my opinion, the authentication is the most sensitive one > of all modules because it can break everything > easily and I am still worried about the patch may break the exinsting > environment for a bunch of users in all over the world using sigv2. > > Regards, > Kota > > > 1: https://bugs.launchpad.net/swift3/+bug/1557260 > 2: https://review.openstack.org/#/c/272516 > > (2016/03/14 19:01), Andrey Pavlov wrote: >> Hello, >> >> I found that new Amazon tool for S3 started to use another way to sign >> requests. >> I made changes and submitted my review [1] seven months ago. >> >> This functionality is needed for ec2api project [2]. >> It is needed for using new aws cli tool. >> >> I asked to review my changes directly to Kota via email. >> My colleague asked him on previous summit about it. >> All dependent reviews (in keystone) already merged four months ago. >> On all comments were answered in the review. >> I tried to raise this question at swift3 meeting. >> >> But still there is no answer. >> >> Can anyone answer - Can it really be reviewed and merged? >> >> [1] https://review.openstack.org/#/c/211933/ >> [2] https://review.openstack.org/#/c/198571/ >> > > > -- > -- > Kota Tsuyuzaki(露﨑 浩太) <tsuyuzaki.k...@lab.ntt.co.jp> > NTT Software Innovation Center > Cloud Solution Project > Phone 0422-59-2837 > Fax0422-59-2965 > --- > > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [swift3][swift] What happens in swift3?
Hello, I found that new Amazon tool for S3 started to use another way to sign requests. I made changes and submitted my review [1] seven months ago. This functionality is needed for ec2api project [2]. It is needed for using new aws cli tool. I asked to review my changes directly to Kota via email. My colleague asked him on previous summit about it. All dependent reviews (in keystone) already merged four months ago. On all comments were answered in the review. I tried to raise this question at swift3 meeting. But still there is no answer. Can anyone answer - Can it really be reviewed and merged? [1] https://review.openstack.org/#/c/211933/ [2] https://review.openstack.org/#/c/198571/ -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] Updating a volume attachment
Hello Shoham, We've tried to write and implement similar spec [1]. And someone have tried to implement it [2]. You can see comments in it. [1] - https://review.openstack.org/#/c/234269/ [2] - https://review.openstack.org/#/c/259518/ On Thu, Feb 11, 2016 at 8:20 PM, Shoham Peller <shoham.pel...@stratoscale.com> wrote: > Thank you Andrea for your reply. > > I know this spec and it is indeed a viable solution. > However, I think allowing users to update the attachment detail, rather than > detach and re-attach a volume for every change is more robust and more > convenient. > > Also, IMHO it's a better user-experience if users can use a single API call > instead of detach API call, poll for the detachment, re-attach the volume, > and poll again for the attachment if they want to powerup the VM. > The bdm DB updating, can happen from nova-api, without IRC'ing a compute > node, and thus return only when the request has been completed fully. > > Don't you agree it's needed, even when detaching a boot volume is possible? > > Shoham > > On Thu, Feb 11, 2016 at 7:04 PM, Andrea Rosa <andrea.r...@hpe.com> wrote: >> >> Hi >> >> On 11/02/16 16:51, Shoham Peller wrote: >> > if the volume we want to update is the boot >> > volume, detaching to update the bdm, is not even possible. >> >> You might be interested in the approved spec [1] we have for Mitaka >> (ref. detach boot volume). >> Unfortunately the spec was not part of the high-priority list and it >> didn't get implemented but we are going to propose it again for Newton. >> >> Regards >> -- >> Andrea Rosa >> >> [1] >> >> http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/detach-boot-volume.html >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] removing EC2 related code from nova
Could anyone (and especially Dan, Hans, or Ryan) check my changes? There is no new code ) only removing old code and dependency to 'boto' library. https://review.openstack.org/#/c/266425/ -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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][ec2-api] Moving EC2 Auth and S3Token to Externally supported
swift3(s3) works like ec2-api. 1. swift3/ec2-api recieves AWS request 2. it parses signature and access_key (and other headers) 3. it sends these values (and token that calculated from request) to keystone 4. keystone gets secret_key from DB, then calculates signature by recieved access_key and token 5. keystone compares recived signature and claculated signature and then return 'error' or auth_token 6. swift3/ec2-api recieves answer from keystone and return 'forbidden' or continues execution 7. in case of continue swift3/ec2-api uses recieved auth_token for calls other services: nova, cinder, neutron, swift... So I don't understand how implement this functionality outside of keystone... On Fri, Feb 5, 2016 at 8:55 PM, Tim Bell <tim.b...@cern.ch> wrote: > >> >> Is it certain that there is no need for the functions with the new EC2-API >> functions ? >> >> The S3 functions are somewhat separated from the EC2 API. How does SWIFT >> implement the S3 compatibility layer ? >> >> Getting a ‘to be deprecated’ log entry into Mitaka would be useful to make >> sure we’re not using it somewhere else. >> > > This would be just a deprecation warning. Removal would be determined at a > later time with sufficient lead time. > > Do you know how S3 with SWIFT works ? Would they need to do something like > EC2-API ? > > Tim > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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][ec2-api] Moving EC2 Auth and S3Token to Externally supported
Can it be implemented as keystone plugin? Is it possible to 'get' AUTH_TOKEN outside of keystone? Will this code use keystone DB or it should create own? So we will need one 'auth' module for swift3/ec2-api. Sounds good but we need to understand some details before implementation. On Fri, Feb 5, 2016 at 10:03 PM, Dolph Mathews <dolph.math...@gmail.com> wrote: > > On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov <andrey...@gmail.com> wrote: >> >> swift3(s3) works like ec2-api. >> >> 1. swift3/ec2-api recieves AWS request >> 2. it parses signature and access_key (and other headers) >> 3. it sends these values (and token that calculated from request) to >> keystone >> 4. keystone gets secret_key from DB, then calculates signature by >> recieved access_key and token >> 5. keystone compares recived signature and claculated signature and >> then return 'error' or auth_token >> 6. swift3/ec2-api recieves answer from keystone and return 'forbidden' >> or continues execution >> 7. in case of continue swift3/ec2-api uses recieved auth_token for >> calls other services: nova, cinder, neutron, swift... >> >> So I don't understand how implement this functionality outside of >> keystone... > > > EC2 support is implemented in middleware on top of keystone, and that > middleware happens to live in the openstack/keystone repository. This change > is just proposing to move that middleware code into a dedicated new > repository and change the community support & maintenance model - it would > not affect how the code actually operates. The only affect on operators is > that it would require an extra step to deploy it. End users would not be > affected. > > https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/keystone/contrib/ec2/routers.py#L27 > > https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/etc/keystone-paste.ini#L27-L31 > >> >> >> On Fri, Feb 5, 2016 at 8:55 PM, Tim Bell <tim.b...@cern.ch> wrote: >> > >> >> >> >> Is it certain that there is no need for the functions with the new >> >> EC2-API >> >> functions ? >> >> >> >> The S3 functions are somewhat separated from the EC2 API. How does >> >> SWIFT >> >> implement the S3 compatibility layer ? >> >> >> >> Getting a ‘to be deprecated’ log entry into Mitaka would be useful to >> >> make >> >> sure we’re not using it somewhere else. >> >> >> > >> > This would be just a deprecation warning. Removal would be determined at >> > a >> > later time with sufficient lead time. >> > >> > Do you know how S3 with SWIFT works ? Would they need to do something >> > like >> > EC2-API ? >> > >> > Tim >> > >> > >> > __ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> >> >> -- >> Kind regards, >> Andrey Pavlov. >> >> ______ >> OpenStack Development Mailing 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 > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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][ec2-api][swift] Moving EC2 Auth and S3Token to Externally supported
As I know 'swift3' project implements S3 for OpenStack over swift. Or your mention something other? (but it doesn't support some features - signature v4 for instance) Andrey. On Fri, Feb 5, 2016 at 10:46 PM, Tim Bell <tim.b...@cern.ch> wrote: > > > > > > On 05/02/16 20:15, "Andrey Pavlov" <andrey...@gmail.com> wrote: > >>Can it be implemented as keystone plugin? >>Is it possible to 'get' AUTH_TOKEN outside of keystone? >>Will this code use keystone DB or it should create own? >> >>So we will need one 'auth' module for swift3/ec2-api. >>Sounds good but we need to understand some details before implementation. >> >>On Fri, Feb 5, 2016 at 10:03 PM, Dolph Mathews <dolph.math...@gmail.com> >>wrote: >>> >>> On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov <andrey...@gmail.com> wrote: >>>> >>>> swift3(s3) works like ec2-api. >>>> >>>> 1. swift3/ec2-api recieves AWS request >>>> 2. it parses signature and access_key (and other headers) >>>> 3. it sends these values (and token that calculated from request) to >>>> keystone >>>> 4. keystone gets secret_key from DB, then calculates signature by >>>> recieved access_key and token >>>> 5. keystone compares recived signature and claculated signature and >>>> then return 'error' or auth_token >>>> 6. swift3/ec2-api recieves answer from keystone and return 'forbidden' >>>> or continues execution >>>> 7. in case of continue swift3/ec2-api uses recieved auth_token for >>>> calls other services: nova, cinder, neutron, swift... >>>> >>>> So I don't understand how implement this functionality outside of >>>> keystone... >>> >>> >>> EC2 support is implemented in middleware on top of keystone, and that >>> middleware happens to live in the openstack/keystone repository. This change >>> is just proposing to move that middleware code into a dedicated new >>> repository and change the community support & maintenance model - it would >>> not affect how the code actually operates. The only affect on operators is >>> that it would require an extra step to deploy it. End users would not be >>> affected. >>> >>> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/keystone/contrib/ec2/routers.py#L27 >>> >>> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/etc/keystone-paste.ini#L27-L31 > > > However, looking at the current state of deployments, the EC2-API is close to > production ready, CERN has been working with the community to get an RPM > package and a Puppet module for configuring it at scale. > > In comparison, the equivalent S3 support would need some further effort to > develop an S3-API project, package and configure it. Given the CERN EC2 > experience, this is several months of work. > > Thus, I have no problem with a message saying this function is on the way out > but there is currently no equivalent function for S3 support (or project > ownership to implement it). I would advise to address these questions before > we start on the road to deprecation on the same time scales as the EC2 > functions. > > Removing function without a migration/alternative would be unpopular with the > user community. According to > http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up, > around 29% of production sites use S3. Personally, that feels a bit high but > it does give an indication of the deployment level. > > How about we split the EC2 deprecation from the S3 one ? > > Tim > > >>> >>>> >>>> >>>> On Fri, Feb 5, 2016 at 8:55 PM, Tim Bell <tim.b...@cern.ch> wrote: >>>> > >>>> >> >>>> >> Is it certain that there is no need for the functions with the new >>>> >> EC2-API >>>> >> functions ? >>>> >> >>>> >> The S3 functions are somewhat separated from the EC2 API. How does >>>> >> SWIFT >>>> >> implement the S3 compatibility layer ? >>>> >> >>>> >> Getting a ‘to be deprecated’ log entry into Mitaka would be useful to >>>> >> make >>>> >> sure we’re not using it somewhere else. >>>> >> >>>> > >>>> > This would be just a deprecation warning. Removal would be determined at >&g
Re: [openstack-dev] [keystone][ec2-api][swift] Moving EC2 Auth and S3Token to Externally supported
Tim, swift3 calls keystone for authentication (in similar way as ec2api) Andrey. On Fri, Feb 5, 2016 at 11:51 PM, Tim Bell <tim.b...@cern.ch> wrote: > Does Swift3 (for S3 on SWIFT) need Keystone or is it independent ? > > Tim > > > > On 05/02/16 20:57, "Andrey Pavlov" <andrey...@gmail.com> wrote: > >>As I know 'swift3' project implements S3 for OpenStack over swift. Or >>your mention something other? >>(but it doesn't support some features - signature v4 for instance) >> >>Andrey. >> >>On Fri, Feb 5, 2016 at 10:46 PM, Tim Bell <tim.b...@cern.ch> wrote: >>> >>> >>> >>> >>> >>> On 05/02/16 20:15, "Andrey Pavlov" <andrey...@gmail.com> wrote: >>> >>>>Can it be implemented as keystone plugin? >>>>Is it possible to 'get' AUTH_TOKEN outside of keystone? >>>>Will this code use keystone DB or it should create own? >>>> >>>>So we will need one 'auth' module for swift3/ec2-api. >>>>Sounds good but we need to understand some details before implementation. >>>> >>>>On Fri, Feb 5, 2016 at 10:03 PM, Dolph Mathews <dolph.math...@gmail.com> >>>>wrote: >>>>> >>>>> On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov <andrey...@gmail.com> >>>>> wrote: >>>>>> >>>>>> swift3(s3) works like ec2-api. >>>>>> >>>>>> 1. swift3/ec2-api recieves AWS request >>>>>> 2. it parses signature and access_key (and other headers) >>>>>> 3. it sends these values (and token that calculated from request) to >>>>>> keystone >>>>>> 4. keystone gets secret_key from DB, then calculates signature by >>>>>> recieved access_key and token >>>>>> 5. keystone compares recived signature and claculated signature and >>>>>> then return 'error' or auth_token >>>>>> 6. swift3/ec2-api recieves answer from keystone and return 'forbidden' >>>>>> or continues execution >>>>>> 7. in case of continue swift3/ec2-api uses recieved auth_token for >>>>>> calls other services: nova, cinder, neutron, swift... >>>>>> >>>>>> So I don't understand how implement this functionality outside of >>>>>> keystone... >>>>> >>>>> >>>>> EC2 support is implemented in middleware on top of keystone, and that >>>>> middleware happens to live in the openstack/keystone repository. This >>>>> change >>>>> is just proposing to move that middleware code into a dedicated new >>>>> repository and change the community support & maintenance model - it would >>>>> not affect how the code actually operates. The only affect on operators is >>>>> that it would require an extra step to deploy it. End users would not be >>>>> affected. >>>>> >>>>> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/keystone/contrib/ec2/routers.py#L27 >>>>> >>>>> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/etc/keystone-paste.ini#L27-L31 >>> >>> >>> However, looking at the current state of deployments, the EC2-API is close >>> to production ready, CERN has been working with the community to get an RPM >>> package and a Puppet module for configuring it at scale. >>> >>> In comparison, the equivalent S3 support would need some further effort to >>> develop an S3-API project, package and configure it. Given the CERN EC2 >>> experience, this is several months of work. >>> >>> Thus, I have no problem with a message saying this function is on the way >>> out but there is currently no equivalent function for S3 support (or >>> project ownership to implement it). I would advise to address these >>> questions before we start on the road to deprecation on the same time >>> scales as the EC2 functions. >>> >>> Removing function without a migration/alternative would be unpopular with >>> the user community. According to >>> http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up, >>> around 29% of production sites use S3. Personally, that feels a bit high >>> but it does give an indication of the deployment level. >>> >>> How about we
[openstack-dev] [sahara] Fields unset with saharaclient update methods
Hi Sahara folks! I want to bring your attention to the problem that described in this bug: https://bugs.launchpad.net/python-saharaclient/+bug/1534050 It was raised on the previous irc-meeting, but we didn't come to a conclusion. One of the ways to fix it is not-None sentinel object that will be used as a default value in update methods. Here is an example of how it will look like in the client: https://review.openstack.org/#/c/272503/ Please, post your thoughts about this change and maybe other ways of fixing this problem there or to the patch set. Thanks. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [OpenStack-Infra] [tempest]
Hello, How to run external tempest plugins in the gating? Now tempest doesn't containt thirdparty tests... They was removed in [1]. And now they present in someone repository [2] and in several forks. I know how to run tempest plugin in the gating if tempest plugin is contained in one of installed package. (I did such job for ec2api gating [3]) But what is the way to run tempest plugin in gating when this plugin is implemented in external repository that link to it doesn't present neither in requirements.txt nor in other places? [1] https://review.openstack.org/#/c/222737/ [2] https://github.com/mtreinish/tempest_ec2 [3] https://review.openstack.org/#/c/246890/ -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] 'NetworkNotFound' exception during listing ports
Hello, I have a problem - when I run tests in parallel then one/two can fail. As I see in logs one thread is deleting network while second thread is listing all ports. And second thread get result 'NetworkNotFound'. Part of neutron service logs is here - http://paste.openstack.org/show/482292/ What I can do to understand what happens more clearly? -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-infra] Functional tests in the gate
For example - https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/ec2-api.yaml#L45 this job has next lines: export DEVSTACK_GATE_TEMPEST=1 export DEVSTACK_GATE_TEMPEST_NOTESTS=1 first line tells to install tempest and second tells that job should not run it and then 'post_test_hook' defines commands to run. On Sun, Dec 6, 2015 at 7:06 PM, Gal Sagie <gal.sa...@gmail.com> wrote: > Hello all, > > I want to write functional tests that will run in the gate but only after > a devstack > environment has finished. > Basically i want to interact with a working enviorment, but i don't want > the tests that i write > to fail the python27 gate tests. > > (I guess like the Neutron full stack tests, but i haven't found how to do > it yet) > > Can anyone please direct me to an example / or help me figure out how to > achieve this? > > Thanks > Gal. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-infra] Functional tests in the gate
Each gating job has own config. This functional test job exports some variable to install devstack. python27/34, pep8 and many other jobs have own configs in the gating. most of jobs use tox`s 'tox.ini' file where command to run is written. On Sun, Dec 6, 2015 at 9:53 PM, Gal Sagie <gal.sa...@gmail.com> wrote: > Thanks for the answer Andrey, > > In the post_test_hook of this, you run the ec2-api functional tests. > What i am asking, is how to prevent these tests from running in > gate-X-python27 for example (which they will > obviously fail as they need a working devstack to run) > > Maybe i am not understanding something fundamental here. > > Gal. > > On Sun, Dec 6, 2015 at 6:56 PM, Andrey Pavlov <andrey...@gmail.com> wrote: > >> For example - >> https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/ec2-api.yaml#L45 >> >> this job has next lines: >> export DEVSTACK_GATE_TEMPEST=1 >> export DEVSTACK_GATE_TEMPEST_NOTESTS=1 >> first line tells to install tempest >> and second tells that job should not run it >> >> and then 'post_test_hook' defines commands to run. >> >> On Sun, Dec 6, 2015 at 7:06 PM, Gal Sagie <gal.sa...@gmail.com> wrote: >> >>> Hello all, >>> >>> I want to write functional tests that will run in the gate but only >>> after a devstack >>> environment has finished. >>> Basically i want to interact with a working enviorment, but i don't want >>> the tests that i write >>> to fail the python27 gate tests. >>> >>> (I guess like the Neutron full stack tests, but i haven't found how to >>> do it yet) >>> >>> Can anyone please direct me to an example / or help me figure out how to >>> achieve this? >>> >>> Thanks >>> Gal. >>> >>> >>> __________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> Kind regards, >> Andrey Pavlov. >> >> __ >> OpenStack Development Mailing 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 , > > The G. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [openstackclient][keystoneclient][devstack] Openstackclient do not work with auth_url without v2.0
I use 'unset OS_AUTH_TYPE' to get it work after sourcing crdentials. On Mon, Nov 30, 2015 at 6:13 AM, lichen.hangzhou <lichen.hangz...@gmail.com> wrote: > Hi guys, > > I re-installed my devstack environment recently on ubuntu 14.04 > > I try to use openstackclient command with devstack created user: > source devstack/accrc/admin/admin > openstack project list > > The command failed with error : The resource could not be found. (HTTP > 404). > And, the issue can be solved by change the auth_url with a v2.0 at the end > : export OS_AUTH_URL=http://9.197.45.36:35357/v2.0 > > I reported a bug > https://bugs.launchpad.net/python-keystoneclient/+bug/1519624 and > submitted a fix https://review.openstack.org/#/c/249578/. > > Because When I run openstackclient command with --debug, and I get log : > http://paste.openstack.org/show/479950/. > From the log, it is easy to see openstackclient already figured out this > command should sent to keystoneclient v2 even there is no v2.0 in the > environment setting. > So, I think this is a bug for keystoneclient. > But, some other guys do not agree with that, because keystoneclient > shouldn't have to check and parse URL bits like that. > > I do not really understand why keystoneclient can not do that. > > And, for openstack users, do they must explicit set the version of > keystone ? > While, I tested, with the same environment settings, > novaclient/glanceclient/neutronclient all can work, the issue only happenes > when we using openstacklcient. > > So, anyone can explain a little bit more why to me ? > > Thanks. > -chen > > > > > > > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [ec2-api] EC2API Liberty release
Hello all, We've released new packages of EC2API project on pypi.python.org - [1] 1.0.0 is a release for OpenStack Liberty and 0.2.0 is an update for OpenStack Kilo [1] https://pypi.python.org/pypi/ec2-api -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [ec2api] stable/liberty release?
We are planning to cut liberty release and kilo update this or next week. (Because we are waiting a response for one small issue.) -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [rally] Neutron or nova degradation?
Hello, We have rally job with fake virt driver. And we run it periodically. This job runs 200 servers and measures 'show' operations. On 18.08 it was run well[1]. But on 21.08 it was failed by timeout[2]. I tried to understand what happens. I tried to check this job with 20 servers only[3]. It passed but I see that operations with neutron take more time now (list subnets, list network interfaces). and as result start and show instances take more time also. Maybe anyone knows what happens? [1] http://logs.openstack.org/13/211613/6/experimental/ec2-api-rally-dsvm-fakevirt/fac263e/ [2] http://logs.openstack.org/74/213074/7/experimental/ec2-api-rally-dsvm-fakevirt/91d0675/ [3] http://logs.openstack.org/46/219846/1/experimental/ec2-api-rally-dsvm-fakevirt/dad98f0/ -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [swift3] [s3] [ec2] What preferable way to implement S3 signature verification V4 in keystone projects?
Hi again, Because was no answer to my questions then I have decided to choose and implement first scenario. So now I need to review my patchsets by community: 1) https://review.openstack.org/#/c/211933/ This is patchset for swift3 with new unit tests. It implements checking of headers of signature v4 auth and preparation string to pass it to keystone. 2) https://review.openstack.org/#/c/215481/ This is patchset for keystone. It implements signature v4 calculation and comparison with provided one. 3) https://review.openstack.org/#/c/215325/ This is patchset for devstack. It implements setting of region for checking in swift3. All new code is written in previous architecture style. So please review these patchsets. On Mon, Aug 17, 2015 at 3:52 PM, Andrey Pavlov andrey...@gmail.com wrote: Hi, I'm trying to support AWS signature version 4 for S3 requests. Related bugs:[1] for keystonemiddleware and [2] for swift3: Also keystone doesn't have support for V4 signature verification for S3 (but it supports V4 for EC2 requests). Differences between V1 and V4 can be found here - V1: [3] and V4: [4]. (Signature verification has several differences for EC2 and S3 requests) My question is - how to implement V4 signature verification? I have several scenarios: 1) Leave current architecture. Swift3 will parse authorization info, will calculate StringToSign, will place it in 'X-Auth-Token' and place some additional header with signature version info. s3token will provide these values to keystone. keystone will calculate signature with V4 algorithm and check it. 2) Same as first but without s3token - swift3 will send all info to keystone itself. 3) Same as first but most authorization headers will be parsed by s3token and s3token will send to keystone. I prefer first scenario. But what think keystone team? Current implementation of S3 signature V1 verificatoin has several oddities for me: First oddity for me is in implementation of EC2 and S3 verification in keystone - ec2tokens (in keystone) takes all request parameters, calculates all that it needs, and checks calculated signature with user provided (Because only keystone can securely access secret_key by provided access_key). But signature calculation code is placed in keystoneclient... But s3tokens takes strange 'token' attribute (that calculated outside of keystone), access_key and signature. Then keystone hash token with secret_key (that was obtained from DB by access_key) and checks this result with provided signature. Oddity for me is in different algorithms for similar essences. Next oddity is in swift pipeline for S3 requests - at 'first' request with S3 params recognized by swift3 plugin. It checks authorization information, validates S3 parameters, calculates StringToSign as it described in [3] and places it in 'X-Auth-Token' header. at next step s3token from keystonemiddleware takes X-Auth-Token (that is a StringToSign) from header, sends it to keystone to check authorization. Oddity for me is in s3token that doesn't parse authorization information unlike ec2token from keystonemiddleware. [1] https://bugs.launchpad.net/keystonemiddleware/+bug/1473042 [2] https://bugs.launchpad.net/swift3/+bug/1411078 [3] http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html [4] http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html -- Kind regards, Andrey Pavlov. -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [swift] [swift3] Are there any objections to add scoped tempest job to swift3 pipeline?
Hi, In our EC2-API project we use tempest job with regex tempest.thirdparty.boto. And I didn't find any job that runs tempest against cloud with swift3 plugin. I think that this is a good idea to add to swift3 project pipeline tempest job. It will check functionality of swift3 plugin in real cloud with real requests. Tempests` boto tests have several test with s3 requests. So question to swift3 team - do you have any objections? -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [swift3] [s3] [ec2] What preferable way to implement S3 signature verification V4 in keystone projects?
Hi, I'm trying to support AWS signature version 4 for S3 requests. Related bugs:[1] for keystonemiddleware and [2] for swift3: Also keystone doesn't have support for V4 signature verification for S3 (but it supports V4 for EC2 requests). Differences between V1 and V4 can be found here - V1: [3] and V4: [4]. (Signature verification has several differences for EC2 and S3 requests) My question is - how to implement V4 signature verification? I have several scenarios: 1) Leave current architecture. Swift3 will parse authorization info, will calculate StringToSign, will place it in 'X-Auth-Token' and place some additional header with signature version info. s3token will provide these values to keystone. keystone will calculate signature with V4 algorithm and check it. 2) Same as first but without s3token - swift3 will send all info to keystone itself. 3) Same as first but most authorization headers will be parsed by s3token and s3token will send to keystone. I prefer first scenario. But what think keystone team? Current implementation of S3 signature V1 verificatoin has several oddities for me: First oddity for me is in implementation of EC2 and S3 verification in keystone - ec2tokens (in keystone) takes all request parameters, calculates all that it needs, and checks calculated signature with user provided (Because only keystone can securely access secret_key by provided access_key). But signature calculation code is placed in keystoneclient... But s3tokens takes strange 'token' attribute (that calculated outside of keystone), access_key and signature. Then keystone hash token with secret_key (that was obtained from DB by access_key) and checks this result with provided signature. Oddity for me is in different algorithms for similar essences. Next oddity is in swift pipeline for S3 requests - at 'first' request with S3 params recognized by swift3 plugin. It checks authorization information, validates S3 parameters, calculates StringToSign as it described in [3] and places it in 'X-Auth-Token' header. at next step s3token from keystonemiddleware takes X-Auth-Token (that is a StringToSign) from header, sends it to keystone to check authorization. Oddity for me is in s3token that doesn't parse authorization information unlike ec2token from keystonemiddleware. [1] https://bugs.launchpad.net/keystonemiddleware/+bug/1473042 [2] https://bugs.launchpad.net/swift3/+bug/1411078 [3] http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html [4] http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] [third-party-ci]Tests randomly failing because of lvm
* __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] ][third-party-ci]Running custom code before tests
HI, this file has changed since yesterday, New link is https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/devstack-gate.yaml#L2146 or you can find these lines by yourself - export DEVSTACK_LOCAL_CONFIG=CINDER_ISCSI_HELPER=lioadm export DEVSTACK_LOCAL_CONFIG+=$'\n'CINDER_LVM_TYPE=thin I mean that you can try to change CINDER_ISCSI_HELPER in devstack. On Thu, Aug 13, 2015 at 9:47 AM, Eduard Matei eduard.ma...@cloudfounders.com wrote: Hi, I think you pointed me to the wrong file, the devstack-gate yaml (and line 2201 contains timestamps). I need an example of how to configure tempest to use my driver. I tried EXPORT in the jenkins job (before executing dsvm shell script) but looking at the tempest.txt (log) it shows that it still uses the defaults. How do i overwrite those defaults? Thanks, Eduard __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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] ][third-party-ci]Running custom code before tests
Hi, You can something like this - https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/devstack-gate.yaml#L2201 On Wed, Aug 12, 2015 at 2:11 PM, Eduard Matei eduard.ma...@cloudfounders.com wrote: Hi, Found some more info (finally): i added a function in the script part in the jenkins job and an export -f and it seems it's being called, so now my backend is installed and configured. I'm now trying to configure cinder to use my driver when running but i couldn't find a way to configure it. https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#How_do_I_configure_DevStack_so_my_Driver_Passes_Tempest.3F mentions Sample local.conf. How do i edit that file? I tried exporting TEMPEST_VOLUME_DRIVER... but still the tests seem to use the default driver. Thanks, -- *Eduard Biceri Matei, Senior Software Developer* www.cloudfounders.com | eduard.ma...@cloudfounders.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 -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing 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][ec2tokens] Questions about ec2tokens under keystone v3 api.
As I saw heat`s ec2tokens can work only with keystone v2 URL. It happens because keystone has different responses for v2 and v3 versions for token request by ec2 credentials. I found same problem in our ec2api project and keystonemiddleware project. For example: Patch for our ec2api project will be here - https://review.openstack.org/#/c/209085/2/ec2api/api/__init__.py Patch for keystonemiddleware is here - https://review.openstack.org/#/c/205440/ -- Kind regards, Andrey Pavlov. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
