Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project
On 06/03/2015 03:57 PM, James Page wrote:
[...]
After some discussion with Thomas on IRC, I think this is more than
one effort; The skills and motivation for developers reviewing
proposed packaging changes needs to be aligned IMO - so I think it
makes sense to split the packaging teams between:
Debian/Ubuntu + derivatives
CentOS/Fedora/RHEL + derivatives
So, would this be two packaging teams - on DEB team and one RPM team?
How would those two teams collaborate - or is no collaboration needed?
Btw. I'd like to throw SUSE into the equation but since none of us
participated in the face to face meeting, we need some better
understanding how this could work.
How are you handling Debian and Ubuntu differences? How shall we handle
differences between RPM distros?
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,
HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] python-novaclient 2.26.0 released
The Nova team is beside themselves with glee to release python-novaclient 2.26.0. https://pypi.python.org/pypi/python-novaclient/2.26.0 Changelog: acf6d1f Remove unused novaclient.tests.unit.v2.utils module 3502c8a Add documentation on command deprecation process 23f1343 Deprecate volume/volume-type/volume-snapshot CRUD CLIs/APIs e649cea Do not check requirements when loading entry points 0a327ce Eliminate test comprehensions aa4c947 Remove redundant check for version of `requests` 22569f2 Use clouds.yaml for functional test credentials 6379287 pass credentials via config file instead of magic 9cfecf9 server-group-list support 'all_projects' parameter de4e40a add ips to novaclient server manager NOTE: The volume APIs/CLIs are now deprecated and will be removed in the first python-novaclient release after the Nova 2016.1 Mujina release. -- 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
[openstack-dev] [cloudpulse] Cloudpulse development team meeting IRC
Hello everyone, I have set up weekly IRC meeting for Cloudpulse - OpenStack health service development. Following is the meeting info: Bi-Weekly Odd on Thursday at 2300 UTC in #openstack-meeting Bi-Weeky Even on Thursday at 1600 UTC in #openstack-meeting-3 You can also find the meeting info at http://eavesdrop.openstack.org/#cloudpulse Cloudpulse meeting and agenda details are posted here .. https://wiki.openstack.org/wiki/Meetings/cloudpulse Agenda: Health API and CLI Deep dive: High level architecture and functional modules Module ownership discussion Anyone who is interested in cloudpulse, openstack health service is welcome to join the meeting. Hope the time is good for most people. Thanks, Vinod __ OpenStack Development Mailing 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] Kilo v3 identity problems
I assume that by v3 policy file you're specifically referring to: https://github.com/openstack/keystone/blob/f6c01dd1673b290578e9fff063e27104412ffeda/etc/policy.v3cloudsample.json Which essentially illustrates enforcement of a much more powerful authorization model than most deployers are familiar with today. You'll need to create and consume a domain-based role assignment, for example (do you have a role assigned to your user on the default domain? Are you accessing openstack domain list with a domain-scoped token?). Unless you're ready to experiment with that new policy model, the default policy file is also designed for v3 and it's behavior is probably what you're expecting: https://github.com/openstack/keystone/blob/f6c01dd1673b290578e9fff063e27104412ffeda/etc/policy.json Perhaps policy.v3cloudsample.json is poorly named if it implies that it's somehow a pre-requisite to getting started with the v3 API? On Wed, Jun 3, 2015 at 11:29 AM, Amy Zhang amy.u.zh...@gmail.com wrote: Hi guys, I have installed Kilo and try to use identity v3. I am using v3 policy file. I changed the domain_id for cloud admin as default. As cloud admin, I tried openstack domain list and got the error message saying that I was not authorized. The part I changed in policy.json: cloud_admin: rule:admin_required and domain_id:default, The error I got from openstack domain list: ERROR: openstack You are not authorized to perform the requested action: identity:create_domain (Disable debug mode to suppress these details.) (HTTP 403) (Request-ID: req-2f42b1da-9933-4494-9b39-c1664d154377) Has anyone tried identity v3 in Kilo? Did you have this problem? Any suggestions? Thanks Amy -- Best regards, Amy (Yun Zhang) __ OpenStack Development Mailing 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] [cinder] Rebranded Volume Drivers
There are a couple of cases [1][2] I'm seeing where new Cinder volume drivers for Liberty are rebranding other volume drivers. This involves inheriting off another volume driver's class(es) and providing some config options to set the backend name, etc. Two problems: 1) There is a thought of no CI [3] is needed, since you're using another vendor's driver code which does have a CI. 2) IMO another way of satisfying a check mark of being OpenStack supported and disappearing from the community. What gain does OpenStack get from these kind of drivers? Discuss. [1] - https://review.openstack.org/#/c/187853/ [2] - https://review.openstack.org/#/c/187707/4 [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers -- 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
Re: [openstack-dev] Kilo v3 identity problems
The command requires a domain scoped token. Did you set the environment variable so that OSC uses a domain scoped token? This can be done by providing OS_DOMAIN_NAME instead of OS_PROJECT_NAME. -Lin On Wed, Jun 3, 2015 at 9:29 AM, Amy Zhang amy.u.zh...@gmail.com wrote: Hi guys, I have installed Kilo and try to use identity v3. I am using v3 policy file. I changed the domain_id for cloud admin as default. As cloud admin, I tried openstack domain list and got the error message saying that I was not authorized. The part I changed in policy.json: cloud_admin: rule:admin_required and domain_id:default, The error I got from openstack domain list: ERROR: openstack You are not authorized to perform the requested action: identity:create_domain (Disable debug mode to suppress these details.) (HTTP 403) (Request-ID: req-2f42b1da-9933-4494-9b39-c1664d154377) Has anyone tried identity v3 in Kilo? Did you have this problem? Any suggestions? Thanks Amy -- Best regards, Amy (Yun Zhang) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Rebranded Volume Drivers
On Wed, Jun 3, 2015 at 11:32 AM, Mike Perez thin...@gmail.com wrote: There are a couple of cases [1][2] I'm seeing where new Cinder volume drivers for Liberty are rebranding other volume drivers. This involves inheriting off another volume driver's class(es) and providing some config options to set the backend name, etc. Two problems: 1) There is a thought of no CI [3] is needed, since you're using another vendor's driver code which does have a CI. 2) IMO another way of satisfying a check mark of being OpenStack supported and disappearing from the community. What gain does OpenStack get from these kind of drivers? Discuss. [1] - https://review.openstack.org/#/c/187853/ [2] - https://review.openstack.org/#/c/187707/4 [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers -- 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 This case is interesting mostly because it's the same contractor submitting the driver for all the related platforms. Frankly I find the whole rebranding annoying, but there's certainly nothing really wrong with it, and well... why not, it's Open Source. What I do find annoying is the lack of give back; so this particular contributor has submitted a few drivers thus far (SCST, DotHill and some others IIRC), and now has three more proposed. This would be great except I personally have spent a very significant amount of time with this person helping with development, CI and understanding OpenStack and Cinder. To date, I don't see that he's provided a single code review (good or bad) or contributed anything back other than to his specific venture. Anyway... I think your point was for input on the two questions: For item '1': I guess as silly as it seems they should probably have 3'rd party CI. There are firmware differences etc that may actually change behaviors, or things my diverge, or maybe their code is screwed up and the inheritance doesn't work (doubtful). Yes, it's just a business venture in this case (good or bad, not for me to decide). The fact is we don't discriminate or place a value on peoples contributions, and this shouldn't be any different. I think the best answer is follow same process for any driver and move on. This does point out that maybe OpenStack/Cinder has grown to a point where there are so many options and choices that it's time to think about changing some of the policies and ways we do things. In my opinion, OpenStack doesn't gain much in this particular case, which brings me back to; remove all drivers except the ref-impl and have them pip installable and on a certified list based on CI. Thanks, John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Rebranded Volume Drivers
On 06/03/2015 01:32 PM, Mike Perez wrote: There are a couple of cases [1][2] I'm seeing where new Cinder volume drivers for Liberty are rebranding other volume drivers. This involves inheriting off another volume driver's class(es) and providing some config options to set the backend name, etc. Two problems: 1) There is a thought of no CI [3] is needed, since you're using another vendor's driver code which does have a CI. 2) IMO another way of satisfying a check mark of being OpenStack supported and disappearing from the community. What gain does OpenStack get from these kind of drivers? To CI or not to CI? That is up to the cinder team to decide. Any CI account in gerrit needs to follow the infra requirements, anything else is up to the project to decide, in this case, cinder. Thanks Mike, Anita. Discuss. [1] - https://review.openstack.org/#/c/187853/ [2] - https://review.openstack.org/#/c/187707/4 [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers -- 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 __ OpenStack Development Mailing 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] [nova] [oslo] [cross-project] Dynamic Policy
On 06/03/2015 10:10 AM, Adam Young wrote: I gave a presentation on Dynamic Policy for Access Control at the Summit. https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/dynamic-policy-for-access-control My slides are here: http://adam.younglogic.com/presentations/dynamic_policy.pp.pdf My original blog post attempted to lay out the direction: http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/ And the Overview spec is here: https://review.openstack.org/#/c/147651/ This references multiple smaller specs: A unified policy file: https://review.openstack.org/134656 The unified policy file, as an actual single file is part of this process which I'm concerned isn't workable unless all OpenStack components are upgraded lock step, which is actually a situation we want to do less of, not more of. Assume that Keystone git tree owns that file. Nova adds an API via microversions for an intermediate milestone that adds new policy in. Deployers CD this version out, leaving Keystone at the previous release version. Now Nova has code out there that requires policy which doesn't exist. The policy at some level is really linked to the code. In a world of microversions this is now a lot more like database schema, because big bang API changes are a thing of the past (at least on the Nova side). (Note: I'm working up some more general explanation of that whole model shortly, part of our comms plan out of summit). -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
[openstack-dev] [Ironic] Weekly subteam status report
Hi, Following is the subteam report for Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and formatted. Bugs (dtantsur) (As of Mon, 1 Jun 17:00 UTC) Open: 150 (+2) 5 new (-2), 45 in progress (+3), 0 critical, 10 high (+3) and 12 (+2) incomplete Neutron/Ironic work (jroll) - first ironic/neutron integration meeting held on Monday; went well - expect specs from BertieFulton (how do we store physical network info) Jim (how do we flip around networks) - shouldn't need nova or neutron specs Oslo (lintan) == pycadf 1.0.0 will be released Nova Liaisons (jlvillal mrda) === https://wiki.openstack.org/wiki/Nova-Ironic-Bugs (1-Jun-2015) Drivers == iLO (wanyen) -- 05:09:01 rameshg87 devananda: regarding ilo driver 3rd party ci, we are almost done with all hp-internal stuffs for enabling it (need to complete it before enabling but still some minor things left so likely will complete it before summit devananda: this could be run as non-voting job on the gate, but given limited hardware, may be better for a periodic job iRMC (naohirot) - https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:open+project:openstack/ironic,n,z The primary focus of iRMC team is to make iRMC driver be consistent with other vendor drivers. Based on this direction, iRMC team is working on the following items: - iRMC Virtual Media Deploy Driver, current status is Coding has Done and Review in Progress. Deploy Driver Base patch which implemented: bp/irmc-virtualmedia-deploy-driver bp/non-glance-image-refs bp/automate-uefi-bios-iso-creation On top of the base, following up patches implemented: bp/local-boot-support-with-partition-images bp/whole-disk-image-support bp/ipa-as-default-ramdisk - Enhance Power Interface for Soft Reboot and NMI bp/enhance-power-interface-for-soft-reboot-and-nmi - The next work item currently iRMC team is investigating: bp/ironic-node-properties-discovery Full speed ahead. Until next week, --ruby [0] https://etherpad.openstack.org/p/IronicWhiteBoard __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
