Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats
Interesting, thanks for trying that. I think this is the time people feel the most. It should help set expectations on how long it will take to get your change into trunk. It seems, on average, to take two weeks. Hopefully it is useful to spot reviews that are proving tricky to get in, and they can be given some extra attention. I agree, its hard to give anyone a goal on this one. We could try count aggregate time on waiting for a reviewer throughout the life of the patch, but I am not sure that will be any more useful. John On 28 June 2013 03:42, Russell Bryant rbry...@redhat.com wrote: Greetings, The key metric I have been using for knowing whether we are keeping up with review requests is the average wait time for getting a review. In a previous thread, we set a goal of keeping that under 4 days (at least by the end of the week, may be higher after a weekend). This is calculated using the time that the *latest* patch revision was posted. We have been keeping up with this (Nova at 3.5 days right now). I've been getting a lot of complaints this week about review turnaround. It's important to me that we're doing this well, but action needs to be based on real data. One of the theories was that patches are having to be rebased a bunch, so they have been waiting longer than the stats say. True, but by how much? The answer is now in the stats: http://russellbryant.net/openstack-stats/all-openreviews.html The results are much better than I was afraid of. On average across all projects, patches waiting for review have an age of just under 14 days since they were first posted. Nova is below average, sitting at an average of just over 10 days. That doesn't seem bad at all, to me. So, if we have a problem, it's not Nova specific, at least. It's harder to set a goal for this metric since it's not entirely in the hands of reviewers like the other one. Suggestions for additional tweaks welcome. Thanks, -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [PTLs] Proposed simplification around blueprint tracking
Thierry Carrez wrote: Thierry Carrez wrote: A script will automatically and regularly align series goal with target milestone, so that the series and milestone views are consistent (if someone sets target milestone to havana-3 then the series goal will be set to havana). Now if the Launchpad API was exporting the series goal property, that would be easier... investigating workarounds. OK, my patch to properly expose series goal in the Launchpad API just went in, so we are unblocked. I now have a script that we can run regularly that will adjust the series goal automatically based on the content of the target milestone. So the plan is, for every project: 1- I'll create a future series with next and ongoing milestones 2- You'll look into blueprints that are in your havana plan (https://blueprints.launchpad.net/PROJECT/havana) but without a milestone set, and consider moving them to one of those milestones in future (or set a havana milestone target if appropriate) 3- We'll enable the script, which will clear all havana blueprints that don't have a milestone target set (see (2)) 4- From then on, blueprints proposers will just need to set a target milestone, and drivers will just need to regularly look at Undefined blueprints and set a priority for them based on how much they care: - Essential: Would prefer not to release without that feature - High: Important feature that we should have in the release - Medium: Optional feature that should still be part of the roadmap - Low: Optional feature that we should *not* follow on the release radar (a.k.a. stop blaming me if it doesn't make it) We'll review all this plan at the next project/release status meeting before giving it the final go. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] Unified logging and Eventlet conflict
On Thu, Jun 27, 2013 at 11:35 PM, Adam Young ayo...@redhat.com wrote: On 06/27/2013 08:43 AM, Davanum Srinivas wrote: Lance, Doug, Looks like eventlet.patcher.is_monkey_**patched(thread) is a reasonable check to switch to to a thread-local implementation. Doesn't it make more sense to have anything Eventlet based explicitly activated? For Keystone, we have isolated all monkeypatching to be done by the process that starts the Keystone server. Adding an additional call in there to activate the thread local storage for greenthreads is reasonable from our perspective. In principle does, but I think that would require more changes. When we get to the point where other services aren't using eventlet, it might make sense to change the default (OTOH, we may be able to drop the use of the locals module altogether at that point, too, I don't know). Doug, did you mean threading.local with WeakValueDictionary? Yes, that looks like it would let us match up the semantics. Doug -- dims On Thu, Jun 27, 2013 at 8:15 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote: This isn't something the deployer controls, so I don't know if we want it to go into a config setting. If we can't detect eventlet being used automatically, we could provide an initialization function in the locals module so projects could change the behavior when a process starts. The default mode would need to be eventlet, for now, but a thread-local implementation seems like an obvious alternative. And of course we would need the module to behave as it does now if the initialization is not explicitly called. Doug On Thu, Jun 27, 2013 at 8:03 AM, Davanum Srinivas dava...@gmail.com wrote: Lance, is eventlet installed a strong enough check? given that folks may pick up a python install that has eventlet installed w/o realizing it? Is there a way to check if the openstack process the code is running in is using eventlet or not? or the other choice is a flag in logging conf to switch to a non-eventlet implemenation? -- dims On Wed, Jun 26, 2013 at 8:17 PM, Lance D Bragstad ldbra...@us.ibm.com wrote: Hey all, Recently there has been some push to get a unified logging implementation pulled from Oslo-incubator into Keystone (Blueprint: https://blueprints.launchpad.**net/keystone/+spec/unified-** logging-in-keystonehttps://blueprints.launchpad.net/keystone/+spec/unified-logging-in-keystone ). Keystone has been actively working to isolate eventlet code within Keystone and bringing in the current implementation from Oslo-incubator would go against that work, as /oslo-incubator/openstack/**common/log.py imports /oslo-incubator/openstack/**common/local.py which has a dependency on eventlet (https://github.com/openstack/**oslo-incubator/blob/master/** openstack/common/local.py#L22https://github.com/openstack/oslo-incubator/blob/master/openstack/common/local.py#L22 ) and is used for storing references to contexts. I know there has been a couple of projects looking to not be dependent on eventlet and thought this might be a good topic for the mailing list, especially if these changes end up in Oslo-incubator. After discussion with a couple of the Keystone members, one option is to tweak local.py to check if eventlet is even installed (similar to def _ensure_subprocess here: https://github.com/openstack/**python-keystoneclient/blob/** master/keystoneclient/common/**cms.py#L11https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/common/cms.py#L11 ) and if it isn't then try implementing a different WeakLocal store not using corolocal.local. Any other ideas on how to approach this are more than welcome. Thanks! Best Regards, Lance Bragstad Software Engineer - OpenStack Cloud Solutions and OpenStack Development T/L 553-5409, External 507-253-5409 ldbra...@us.ibm.com, Bld 015-2/C118 __**_ OpenStack-dev mailing list OpenStack-dev@lists.openstack.**orgOpenStack-dev@lists.openstack.org http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-devhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com __**_ OpenStack-dev mailing list OpenStack-dev@lists.openstack.**org OpenStack-dev@lists.openstack.org http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-devhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __**_ OpenStack-dev mailing list OpenStack-dev@lists.openstack.**org OpenStack-dev@lists.openstack.org http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-devhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __**_ OpenStack-dev mailing list OpenStack-dev@lists.openstack.**org OpenStack-dev@lists.openstack.org
Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats
On Fri, Jun 28, 2013 at 12:12 PM, Russell Bryant rbry...@redhat.comwrote:The results are much better than I was afraid of. On average across all projects, patches waiting for review have an age of just under 14 days since they were first posted. Nova is below average, sitting at an average of just over 10 days. That doesn't seem bad at all, to me. FWIW that matches pretty closely with my experience with the v3 api patches for which there have been a reasonable volume of changesets with pretty similar review complexity. From submission to merging, if there are no or only very minor issues with the changeset, then it takes around two weeks. I think its a very useful stat to have (and to monitor) so people have a rough idea of how long before a reasonably well polished changeset needs to be submitted before a deadline. In most cases, except perhaps for fairly simple bug fixes, I think pushing something just a week before is being pretty optimistic. Suggestions for additional tweaks welcome. How about time since first revision or -1 applied (but not including -1s by Jenkins due to gate flakiness), whichever is shorter. That eliminates non trivial rebases which I've found are often required after about 7 days but doesn't push out the numbers where the submitter is slow in updating. Regards, Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Http library usage by clients
On Fri, Jun 28, 2013 at 10:12 AM, Steven Hardy sha...@redhat.com wrote: Obviously long-term a keystone native way to sign requests would be great, and could be used by Heat, and e.g Swift which has it's own method for generating pre-signed URLs. fyi: only when you are using the temporary url feature you are generating pre-signed URL (compared to S3 where it's always I think). Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Rating engine for BillingStack
Hi, I would like to get some input on what kind of rating rules engine we could use for BS. Basically there are two alternatives as we see it now: Drools as a service besides the Python components in BS using https://github.com/droolsjbpm/drools-wb as a UI and interact with it as a webservice Python Intellect Does anyone else have input on the matter? Endre ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Http library usage by clients
On 06/27/2013 10:45 PM, Simo Sorce wrote: On Thu, 2013-06-27 at 17:49 -0700, Clint Byrum wrote: On 2013-06-27 16:28, Jamie Lennox wrote: On Fri, 2013-06-28 at 07:01 +1200, Robert Collins wrote: On 27 June 2013 04:55, Adam Young ayo...@redhat.com wrote: Right now Keystone provides so called bearer tokens: This means that whoever has a token can do whatever the token entitles him to do. If I manage to get somebody's token I can do whatever this person is able to do. To fix it, the other services that use tokens to: 1. Authenticate the identity 2. Match the name in the token to the identity that authenticated the connection. I am confused: HTTP is a message orientated protocol, connection based authentication is a terrible antipattern. Do you really mean 'connection' here? More the HTTPs handshake i guess, the point is to have for example a client certificate or kerberos identity that is used to connect to the individual servers. When a token is generated from keystone we put into the token a reference to the kerberos or cert that was used to generate the token, then when this token is used on a server the auth_token middleware ensures that the same kerberos principal or certificate is used to make that connection as made the original. That means even if you get the token unless you have the cert/kerberos id you can't use it. The full blueprint is: https://blueprints.launchpad.net/keystone/+spec/authentication-tied-to-token So you need the cert/kerberos ticket to both create and use the token. So this means you are really trying to solve the problem of us transmitting whole tokens for each request, making them open to interception during transmission or theft from backing storage. If the names match then you can be sure that the user that connected to the service and presented a token is the same user that acquired the token from keystone in the first place. That would prevent the use case of 'create a token and hand it off' which AIUI Heat depends on/will depend on. Yes it would, but this is where heat would need to make use of the trusts mechanism that was released with Grizzly, something that i understand is planned anyway. Indeed it is. But right now, the most excellent make an EC2 keypair and sign stuff with it scheme is working out pretty well. That scheme at least eliminates the transmission vulnerability. Using a private key to sign requests is certainly an option that is certainly to be considered. It was considered. However, when you get down to the management of those keys, and how to sign the messages, it is no less complex than dealing with X509 Certificates, and X509 is already implemented. X509 has a format for authentication information in a separate signed document from the initial certificate itself, but deployment of it is not very wide spread. From our perspective, it makes more sense to continue to use Keystone tokens for authorization information, and link it to a secure Authentication source. We are giving people the choice between X509 and Kerberos out the door, although any other secure authentication source would be viable as well. In order to do that thought it would be easier if all clients would use the same http library and keystone client so that signing can also be done mostly transparently to the clients by hooking into the http library and signing the request before it is sent. Simo. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [PTLs] Proposed simplification around blueprint tracking
On 19/06/13 15:51 +0200, Thierry Carrez wrote: Thoughts ? Although it is not an integrated project - not even incubated - we've been doing this for Marconi as well and it's been quite a pain. Also, I've been following how Glance's blueprints have evolved and again, I've noticed how hard it is to keep those fields synced and updated. So, a big +1 from my side. Cheers, FF -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Sample config file location inconsistency
On 25/06/13 11:03 +0800, Zhongyue Luo wrote: Hi team I'm currently trying to move the generate_sample.sh script in nova to oslo. Before pushing the patch to gerrit, I wanted to give the output directory a default value if it was not stated so I was wondering where projects put their sample config file at and did this: find . -name *.conf* ! -path *.tox* ! -path *.venv* | grep etc results: ./ceilometer/etc/ceilometer/ceilometer.conf.sample ./cinder/etc/cinder/cinder.conf.sample ./nova/etc/nova/nova.conf.sample ./swift/etc/swift.conf-sample ./tempest/etc/tempest.conf.sample ./glance/etc/glance-cache.conf ./quantum/etc/quantum.conf ./keystone/etc/keystone.conf.sample You can see that ceilometer, cinder, and nova put their sample config files on ./etc/$PROJECTNAME while the others put it on ./etc So would this inconsistency be a problem? IMO, ./etc/$PROJECTNAME makes sense to me if consistency is an issue. Thoughts? FWIW, I don't think this is an issue but I also prefer etc/$PROJECTNAME Cheers, FF -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Http library usage by clients
On 06/27/2013 10:35 AM, Thierry Carrez wrote: Adam Young wrote: Right now Keystone provides so called bearer tokens: This means that whoever has a token can do whatever the token entitles him to do. If I manage to get somebody's token I can do whatever this person is able to do. Right. Tokens are considered secrets for that reason. To be specific, symmetric shared secrets. To fix it, the other services that use tokens to: 1. Authenticate the identity 2. Match the name in the token to the identity that authenticated the connection. If the names match then you can be sure that the user that connected to the service and presented a token is the same user that acquired the token from keystone in the first place. That sounds like an extra layer of security rather than a fix ? If you consider bearer tokens to be sufficient security, then yes. If, on the other hand, bearer tokens are seen as a security risk, then it is a fix. To make this happen we need to add authentication to the connections between clients and services. To be able to do that we need to 1. Enable multiple forms of authentication per client. The best way to do this is to use a common client library, which we have developed in keystoneclient 2. Use the 'requests' libraray for HTTP across all clients 3. Enable running the API servers in Apache HTTPD. Making Eventlet support X509 CLient certs and Kerberos is going to be difficult, and the likelihood of introducing a security problem is high. Devil's advocate says: the key idea behind Keystone was to centralize authentication, though. Doesn't this extra layer kind of defeat that ? Why would you need tokens at all, with a strongly-authenticated connection to the API servers ? Keystone centralizes both authentication and authorization. It offloads the need to store passwords from all of the various services to Keystone. However, authentication based solely on userid/password has a well documented body of known issues. I am proposing that we use the more secure mechanisms for authentication, and limit keystone's role to authorization data. [...] So this raises a couple of points. - We need to get Nova, Quantum and Cinder to use keystoneclient. I'm actually surprised that they don't, so +1 :) - Eventlet is mostly gone from the clients already. I'm not sure how many of those http requests would end up actually blocking. +1 - It would appear that clients have all at some point taken a central layout approach and with it taken httplib. We probably can't get them all changed over to requests before we try to add kerberos. I'm not sure they would be so opposed to the idea. Especially considering the next point. - There is already a number of concerns around the way we use https. By default httplib does not verify https certificates, requests does and provides global ways of setting the bundle. https://wiki.openstack.org/wiki/SecureClientConnections already advocates for the transfer to requests with some interesting examples like https://bugs.launchpad.net/python-glanceclient/+bug/1079692 (Server's name isn't verified when using https) We definitely need a more consistent support of https rather than so many different implementations that fail in so many different ways. FWIW we'd consider absence of server cert checking in Python client libraries connections as a vulnerability, so please report as a security bug any occurrence of that. Regards, ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Networking] Allocation of IPs
Aaron, Because the create create_subnet API is the one that enables/disables the DHCP: quantum subnet-create network CIDR --enable_dhcp False Besides, the CIDR is actually the information that is sent to the DHCP to locate IP Addresses. Thanks, Edgar From: Aaron Rosen aro...@nicira.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Thursday, June 27, 2013 8:59 AM To: OpenStack List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Networking] Allocation of IPs Hi Edgar, In this case if you don't associate a subnet with a network you should achieve that. Why doesn't that work? Thanks, Aaron On Thu, Jun 20, 2013 at 1:51 PM, Edgar Magana emag...@plumgrid.com wrote: Could it be possible to add a flag to disable the allocation for the IP? If the no allocation flag is enabled, all ports will have an empty value for IPs. It will increase the config parameters in quantum, should we try it? Edgar From: Mark McClain mark.mccl...@dreamhost.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Thursday, June 20, 2013 1:13 PM To: OpenStack List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Networking] Allocation of IPs There's work under way to make IP allocation pluggable. One of the options will include not having an allocator for a subnet. mark On Jun 20, 2013, at 2:36 PM, Edgar Magana emag...@plumgrid.com wrote: Developers, So far in Networking (formerly Quantum) IPs are pre-allocated when a new port is created by the following def: _allocate_ips_for_port(self, context, network, port): If we are using a real DHCP (not the dnsmasq process) that does not accept static IP allocation because it only allocates IPs based on its own algorithm, how can we tell Networking to not allocate an IP at all? I don¹t think that is possible based on the code but I would like to know if somebody has gone through the same problem and have a workaround solution. Cheers, Edgar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/li stinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Networking] Allocation of IPs
Thanks Mark! Edgar From: Mark McClain mark.mccl...@dreamhost.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Monday, June 24, 2013 7:04 AM To: OpenStack List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Networking] Allocation of IPs Here's the blueprint https://blueprints.launchpad.net/quantum/+spec/configurable-ip-allocation On Jun 21, 2013, at 5:34 PM, Edgar Magana emag...@plumgrid.com wrote: Mark, Can you point me to the BP for this feature? I want to keep an eye on it. Thanks, Edgar From: Mark McClain mark.mccl...@dreamhost.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Friday, June 21, 2013 12:41 PM To: OpenStack List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Networking] Allocation of IPs There will be a deployment option where you can configure the default IP allocator. Additionally, the allocator will be configurable at subnet creation time. mark On Jun 20, 2013, at 4:51 PM, Edgar Magana emag...@plumgrid.com wrote: Could it be possible to add a flag to disable the allocation for the IP? If the no allocation flag is enabled, all ports will have an empty value for IPs. It will increase the config parameters in quantum, should we try it? Edgar From: Mark McClain mark.mccl...@dreamhost.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Thursday, June 20, 2013 1:13 PM To: OpenStack List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Networking] Allocation of IPs There's work under way to make IP allocation pluggable. One of the options will include not having an allocator for a subnet. mark On Jun 20, 2013, at 2:36 PM, Edgar Magana emag...@plumgrid.com wrote: Developers, So far in Networking (formerly Quantum) IPs are pre-allocated when a new port is created by the following def: _allocate_ips_for_port(self, context, network, port): If we are using a real DHCP (not the dnsmasq process) that does not accept static IP allocation because it only allocates IPs based on its own algorithm, how can we tell Networking to not allocate an IP at all? I don¹t think that is possible based on the code but I would like to know if somebody has gone through the same problem and have a workaround solution. Cheers, Edgar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/l istinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/li stinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Http library usage by clients
On 26/06/13 12:55 -0400, Adam Young wrote: Glance: - Uses httplib for communication - Uses keystoneclient within cli - Checks that socket is patched before importing eventlet for httplib. FWIW, we're working on the migration to requests. Cheers, FF -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] CLI command to figure out security-group's association to particular tenant/user
On 06/28/2013 01:55 AM, Rahul Sharma wrote:
Thanks Aaron for your kind help. It worked. Is there any doc which lists
all the possible commands and their usage for quantum? because --help
doesn't help in identifying all the parameters, is there any reference
which one can use to get the complete command syntax?
If you use quantum help command rather than quantum --help, it will
give you more detailed help about command. For example:
$ quantum help security-group-rule-create
usage: quantum security-group-rule-create [-h]
[-f {html,json,shell,table,yaml}]
[-c COLUMN] [--variable VARIABLE]
[--prefix PREFIX]
[--request-format {json,xml}]
[--tenant-id TENANT_ID]
[--direction {ingress,egress}]
[--ethertype ETHERTYPE]
[--protocol PROTOCOL]
[--port-range-min PORT_RANGE_MIN]
[--port-range-max PORT_RANGE_MAX]
[--remote-ip-prefix
REMOTE_IP_PREFIX]
[--remote-group-id SOURCE_GROUP]
SECURITY_GROUP
Create a security group rule.
positional arguments:
SECURITY_GROUPSecurity group name or id to add rule.
optional arguments:
-h, --helpshow this help message and exit
--request-format {json,xml}
the xml or json request format
--tenant-id TENANT_ID
the owner tenant ID
--direction {ingress,egress}
direction of traffic: ingress/egress
--ethertype ETHERTYPE
IPv4/IPv6
--protocol PROTOCOL protocol of packet
--port-range-min PORT_RANGE_MIN
starting port range
--port-range-max PORT_RANGE_MAX
ending port range
--remote-ip-prefix REMOTE_IP_PREFIX
cidr to match on
--remote-group-id SOURCE_GROUP
remote security group name or id to apply rule
output formatters:
output formatter options
-f {html,json,shell,table,yaml}, --format {html,json,shell,table,yaml}
the output format, defaults to table
-c COLUMN, --column COLUMN
specify the column(s) to include, can be repeated
shell formatter:
a format a UNIX shell can parse (variable=value)
--variable VARIABLE specify the variable(s) to include, can be repeated
--prefix PREFIX add a prefix to all variable names
rick jones
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [networking] A consideration about config files and deployment issues
Folks, I appreciate that there is a strong awareness within the dev community to ensure that OpenStack gets easier and easier to be deployed, upgraded and maintained, however I would like to invite core reviewers to think (even) harder about the implications that changes to config files may have for the poor sysadmin guy who has the job of running OpenStack-based clouds (or packagers for that matter). I don't want to pick up on any specific committer/reviewer, but review [1] got me thinking on how patches that tweak configuration files are taken somewhat lightly. The particular change in question has not only implications on how devstack generates these files (and I don't see any devstack patch counter-part currently in review, or being merged to deal with the Neutron change - apology if there is but I couldn't find it), but also implications for Puppet or Chef recipes that rely on config templates based on what etc folders of every project contain. Luckily enough the implications in this specific case are innocuous, but I have personally gotten burnt too many times in the past on this very issue: config files are changed too often without thinking too hard to what it means for who needs to maintain instantiations of these files across multiple releases. This is not meant to be rant, just a kind reminder :) Many thanks, Armando [1] https://review.openstack.org/#/c/34515 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats
On 06/28/2013 08:24 AM, Christopher Yeoh wrote: How about time since first revision or -1 applied (but not including -1s by Jenkins due to gate flakiness), whichever is shorter. That eliminates non trivial rebases which I've found are often required after about 7 days but doesn't push out the numbers where the submitter is slow in updating. Good idea. I've added it as a third stat here: http://russellbryant.net/openstack-stats/all-openreviews.html Average is just under 7 days. Nova is about a day below the average. This probably a bit higher than I'd like to see, but not too far off. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Metrics][Nova] Another take on review turnaround stats
On 06/28/2013 12:18 PM, Matt Riedemann wrote: Hey I made the list! _https://review.openstack.org/#/c/25355/_ Just wanted to point out for nova in longest-waiting reviews based on first revision: 1.94 days, 12 hours, 49 minutes - _https://review.openstack.org/25355_ (PowerVM resize and migrate test cases) This one is a bit skewed because it was abandoned due to inactivity and then I picked it back up by assigning the bug to myself and contributing to the original review. Is there a way to take that into account in the metrics? Or is this a process issue, i.e. should I have left this abandoned and pushed up a new review based on the original? I think what you did is definitely the right thing to do. The stat is still accurate for how long it is taking to get the patch to completion. Having some really high numbers here doesn't worry me, because it's reality, and is often out of the control of reviewers. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] More on inherited domain roles
Hi Adam
if you do it at role assignment time, I think the newly assigned role
should be marked as implicit/inherited to differentiate it from an
explicitly assigned role. In this way, if the inheritance is
subsequently removed, then the inherited assignment can also be deleted
at the same time. I dont think it is the correct model to convert an
inherited role into an explicitly assigned role.
the advantage of doing it with token creation is that the token can
accurately reflect the current state of affairs wrt inheritance and
revocation is not needed (since the token will time out).
regards
david
On 28/06/2013 17:13, Adam Young wrote:
Since I will be gone next week, and I know you want to move on with
this, just wanted to confirm that I am OK with Henry's approach.
I would like to suggest that we contemplate doing to inheritance
mechanism at assignment time as opposed to token creation time as an
optimization. What would this mean?
Say a domain role-assignement implies a project role assignment. When a
new project is created, we generate the role-assignments for the users
that have domain entries explicitly at this point.
The objection I assume would be along the lines of how are you sure you
are going to get it right and that is going to generate a lot more
entries in the database which are both valid concerns. However, token
creation is far, far more common than changes to role assigments, and we
should focus on optimizing for this use case. In addition, it will
remove the need for effective role assignments.
One concern would be with if we drop the inheritance relationship, what
do we do with all those people that have that role already. We would
have the choice of removing the role-assignments then, or of leaving
them in place, and having to manually remove them. We would have no
means to distinguish between explicit and implicit role assignments. I
could entertain arguments on either approach, or even an additional
parameter specifying what to do upon removal of the domain level assignment.
I don't see this as make-or-break but rather an implementation detail
worth considering now.
This would be consistent with the token revocation approach, where we
make the effort to revoke all tokens at the time of the event.
On 06/13/2013 09:49 AM, Henry Nash wrote:
Thanks Guang - I have added responses, as well as tried to articulate
the conceptual differences that actually underpin all these
approaches. This is in the intro in the etherpad, but reproduced below:
Before looking at the possible solutions, it is worth pointing out
that the differences in the various options boil down to how we
approach two conceptual issues:
1) How should we specify an assignment that applies to more than one
entity? There are two conceptual approaches:
- Use Inheritance, based on some grouping, hopefully one that already
exists (e.g. use the fact that all projects are owned by a domain)
- Use a logical expression (e.g. apply to * )
The differences in these two concepts gets amplified if we want to be
able, in the future, to further segregate role assignmnets based on
some other subset (e.g. either hierachy of domains, or 'apply to
domains matching the string army* )
2) Should you specify the scope of the assignment separately from
the assignment?
- Keeping them separate is considered good practice by our experts in
this field, and this can be done by either storing the scope in
another entity (e.g. the role def) or separatly in the assignment call.
- If you don't keep them separate, then obviously it is all lumped
into the assignment call.
The proposed solutions only differ fundamentally in how the approach
these concepts (with consequences in the use cases below), the rest is
just semantics.
Henry
On 12 Jun 2013, at 22:46, Yee, Guang wrote:
Added my comments in the etherpad.
I really think role assignment merits its own CRUD. Since there's a
new API
to get the role assignments.
GET /role_assignments
why not just have the complete API set to facilitate role
assignments? That
way, we have one unified API for role
assignment, as oppose to multiple APIs as exist today.
To get a role assignment:
GET /role-assignments/{role_assignment_id}
To remove a role assignment:
DELETE /role-assignments/{role_assignment_id}
To create a role assignment:
POST /role_assignments
{role_assignment: {
user {
id: user_id
},
role: {
id: role_id
},
scope: {
domain: {
id: domain_id
},
project: {
id: project_id
}
}
}
Note: user and scope is similar to the data structure in auth
APIs. i.e.
can be either id or name + domain.
If assignment is for a group, just have group in there instead of
user.
For example,
{role_assignment: {
group {
id: group_id
},
role: {
id: role_id
},
scope: {
domain: {
id: domain_id
},
project: {
id: project_id
}
}
Re: [openstack-dev] [Networking] Allocation of IPs
Hi Edgar, I'm still not following. In your original question you asked how to you create a port and not allocate an ip address to it at all so that you can leverage a real dhcp server to do that. In order to do that you can create a network without a subnet but then you loose the ipam info in quantum. Or write a script that notifies your dhcp server the mac-ip bindings each instance should have. Am i missing something here? Thanks, Aaron On Thu, Jun 27, 2013 at 11:00 PM, Edgar Magana emag...@plumgrid.com wrote: Aaron, Because the create create_subnet API is the one that enables/disables the DHCP: quantum subnet-create network CIDR --enable_dhcp False Besides, the CIDR is actually the information that is sent to the DHCP to locate IP Addresses. Thanks, Edgar From: Aaron Rosen aro...@nicira.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Thursday, June 27, 2013 8:59 AM To: OpenStack List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Networking] Allocation of IPs Hi Edgar, In this case if you don't associate a subnet with a network you should achieve that. Why doesn't that work? Thanks, Aaron On Thu, Jun 20, 2013 at 1:51 PM, Edgar Magana emag...@plumgrid.comwrote: Could it be possible to add a flag to disable the allocation for the IP? If the no allocation flag is enabled, all ports will have an empty value for IPs. It will increase the config parameters in quantum, should we try it? Edgar From: Mark McClain mark.mccl...@dreamhost.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Thursday, June 20, 2013 1:13 PM To: OpenStack List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Networking] Allocation of IPs There's work under way to make IP allocation pluggable. One of the options will include not having an allocator for a subnet. mark On Jun 20, 2013, at 2:36 PM, Edgar Magana emag...@plumgrid.com wrote: Developers, So far in Networking (formerly Quantum) IPs are pre-allocated when a new port is created by the following def: _allocate_ips_for_port(self, context, network, port): If we are using a real DHCP (not the dnsmasq process) that does not accept static IP allocation because it only allocates IPs based on its own algorithm, how can we tell Networking to not allocate an IP at all? I don’t think that is possible based on the code but I would like to know if somebody has gone through the same problem and have a workaround solution. Cheers, Edgar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
