Re: [openstack-dev] [neutron] [infra] Depends-on tag effect
Hi, iiuc, neutron uses a released version of neutron-lib not neutron-lib master ... So the change should depends on a change in requirements repo incrementing neutron-lib version On Wed, Mar 8, 2017 at 3:16 PM, Hirofumi Ichihara < ichihara.hirof...@lab.ntt.co.jp> wrote: > Hi, > > I thought that we can post neutron patch depending on neutron-lib patch > under review. > However, I saw it doesn't work[1, 2]. In the patches, neutron patch[1] has > Depends-on tag with neutron-lib patch[2] but the pep8 and unit test fails > because the test doesn't use the neutron-lib patch. > > Please correct me if it's my misunderstanding. > > [1]: https://review.openstack.org/#/c/424340/ > [2]: https://review.openstack.org/#/c/424868/ > > Thanks, > Hirofumi > > > > __ > OpenStack Development Mailing 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] [neutron]
Hello, AFAIK, it's not possible. I did a similar thing by extending neutron iptables driver in order to set "pre-rules". Best regards, Cédric/ZZelle On Fri, Nov 18, 2016 at 1:58 PM, Iago Santos Pardo < iago.santos.pa...@cern.ch> wrote: > Hello, > > We are using Neutron with the linuxbridge plugin and security groups > enabled and we have some custom rules in iptables running on the compute > nodes. When the agent rebuilds the firewall it changes the rules order, > putting the neutron chains on the top. Is there any way to preserve the > rules order and tell neutron to ignore our rules or stuck them on the top? > > Thank you so much. > __ > OpenStack Development Mailing 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] [all][tc] "production line" changes to multiple projects
Hi, Project .gitignore should specify untracked files related only to the project and developers should specify in their local .gitignore untracked files related to the way they develop. It seems to be git-scm[1] recommandation: *Patterns which a user wants Git to ignore in all situations (e.g., backup or temporary files generated by the user’s editor of choice) generally go into a file specified by core.excludesFile in the user’s ~/.gitconfig. Its default value is $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore is used instead.* Cedric/ZZelle@IRC [1] https://git-scm.com/docs/gitignore On Sat, Oct 22, 2016 at 1:52 PM, Amrith Kumar <amr...@tesora.com> wrote: > Is there something we can do about the “production line” changes like > > > > https://review.openstack.org/#/q/Update+.gitignore+to+ > ignore+.idea+of+PyCharm > > > > These kinds of changes, and this is by no means the only one, are aimed at > bringing ‘standardization’ to all OpenStack projects. Unfortunately, when > all projects don’t agree with the attempt at standardization, we end up > with a lack of standardization across OpenStack. > > > > How do we go about handling these kinds of changes that are causing a fair > amount of churn with little real benefit? Is there anything we can do or is > the best recommendation that projects just grin and bear it? > > > > -amrith > > __ > OpenStack Development Mailing 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] [neutron] Is this a bug in metadata proxy...
> > I was wondering if the user/group should be (only) set in a common config, > like neutron.conf, if it should be duplicated in dhcp and metadata config > files, or if the metadata ini should be added to the list of ini files, > when starting up the DHCP agent. > Previously, metadata_proxy_user/group were documented in neutron.conf (when a neutron.conf sample was in github repo) in order to deduce metadata_proxy_socket_mode correctly. You can also define them in both l3/dhcp.ini and metadata-agent.ini config files or set explicitly metadata_proxy_socket_mode in metadata-agent.ini. But it's unrelated as your trouble seems to be linked to a metadata_proxy_watch_log misconfiguration and metadata_proxy_user/group/watch_log are all used by dhcp/l3-agents. With the wrong config, I hit the access denied issue and had no info > indicating that is what has happened. Was wondering if there was any > protection against that misconfiguration case, or way to get an indication > of it. > Before dropping privileges, we cannot detect such access deny to log file (because of features like GRsec,PaX, RBAC). After dropping privileges, we can only log to syslog or stdout if we catch an access deny to log file. Cedric/ZZelle@IRC __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Is this a bug in metadata proxy...
Hi, Are you sure metadata_proxy_user==neutron? neutron-metadata-proxy must be able to connect to the metadata-agent socket and watchs its log files and neutron user should be able to do both with usual file permissions. Otherwise the metadata proxy is generally no more able to: - watch log[1] so you should set metadata_proxy_watch_log=False - connect to the metadata-agent because of socket permissions, so you should set metadata_proxy_socket_mode option[2] in order to let the metadata agent set the correct perms on metadata socket. If you provide metadata_proxy_user/group in l3/dhcp-agent and metadata-agent config then neutron should be able to deduce both metadata_proxy_watch_log and metadata_proxy_socket_mode values. [1] https://review.openstack.org/#/c/161494/ [2] https://review.openstack.org/#/c/165115/ Cédric/ZZelle On Wed, Aug 31, 2016 at 2:16 PM, Paul Michali <p...@michali.net> wrote: > Hi, > > I had seen something and was not sure if this was a subtle bug or not. > > I have a Liberty based openstack setup. The account that is setting up > processes was user=neutron, group=neutron, however the metadata_agent.ini > config file was set up for a different group. So there was a > metadata_proxy_user=neutron, and metadata_proxy_group=foo config setting. > > This ini file was used by the metadata agent process, but it was not > included in the DHCP agent process (not sure if I should have included the > metadata_agent.ini in the startup of DHCP or should have added these two > metadata proxy settings to neutron.conf, so that they were available to > DHCP). > > In any case, here is what I saw happen... > > I created a subnet (not using a router in this setup). It looks like DHCP > starts up the metadata agent proxy daemon) and the DHCP configuration is > used, which does NOT include the metadata_proxy_user/group, so the current > user's uid and gid are used (neutron/neutron) for the > metadata_proxy_user/group settings. > > The proxy calls drop_privileges(), which because the group is different, > the log file can no longer be accessed by the daemon. An OSError occurs > with permission denied on the log file for this process, and the process > exits without any indications. > > When I then try to use metadata services it fails (obviously). Looking, we > see that the metadata service is running (but the proxy is not, and I don't > see a way for an end user to check that - is there a way?). > > Looking in the proxy log, the initial startup messages are seen, showing > all the configuration settings, and then there is nothing more. No > indication that it is lowering privileges to run under some other > user/group, that there was a fatal error, or that it is working and ready > to process requests. Nothing more appears in the log, as it was working and > there were no metadata proxy requests occurring. > > I was only able to figure it out, by first checking to see if the proxy > was running, and then manually trying to start the proxy, using the command > line in the log, under a debugger, to find out that there was a permission > denied error. > > So, it is likely a misconfiguration error on the user's part, but it was > really hard to figure that out. > > Should/could we somehow indicate if there is an error lowering privs? > > Is there a (user) way to tell if proxy is running? > > Is there some documentation indicating that the proxy user/group settings > need to be available for both the metadata agent and for other agents that > may spawn the proxy (DHCP, L3)? > > Regards, > > PCM > > > __ > OpenStack Development Mailing 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]keystone v2 bug
Hi,
A token issue is done with a POST request not a GET request, so the request
should be:
curl -X POST ...
and Keystone requires perhaps Accept header.
Cédric/ZZelle
On Mon, Jul 25, 2016 at 3:19 AM, Kenny Ji-work <jenkins-...@qq.com> wrote:
> Hi all,
>
> In the mitaka version, I used v2 RESTful API of keystone as following:
> curl -i -H "Content-Type: application/json" -d '
> { "auth": {
> "tenantName": "admin",
> "passwordCredentials": {
> "username": "admin",
> "password": "password"
> }
> }
> }' http://10.240.227.7:35357/v2.0/tokens ; echo
>
> But the result shows: {"error": {"message": "The request you have made
> requires authentication.", "code": 401, "title": "Unauthorized"}}. But the
> v3 of keystone works normaly.
> Is v2 of keystone not supported in mitaka or something else config I
> config wrong?
>
> Sincerely!
> Kenny Ji
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] Which SSL ca_file does a person use, really?
> > However, I'd be willing to bet there's some cloud out there where at > least one of these services is owned by a separate team than Nova, who > uses a different CA than the rest of things. > It's not really a constraint as a cafile can contain one or more CA(s). Typical examples : * /usr/ssl/certs/ca-certificates.crt in Ubuntu * /etc/pki/tls/certs/ca-bundle.crt in idontremember * cacert.pem in requests python package deployed using pip Cédric/ZZelle __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules
Hi, I understand that it's more user-friendly to enable by default all traffic to VMs, but it seems clearly unsecure to enable by default all traffic to VMs (including ssh from internet!!!), as it increases the VM exposition surface on internet and reduces its security. Cédric/ZZelle On Tue, Mar 1, 2016 at 11:52 PM, Kevin Benton <ke...@benton.pub> wrote: > Hi, > > I know this has come up in the past, but some folks in the infra channel > brought up the topic of changing the default security groups to allow all > traffic. > > They had a few reasons for this that I will try to summarize here: > * Ports 'just work' out of the box so there is no troubleshooting to > eventually find out that ingress is blocked by default. > * Instances without ingress are useless so a bunch of API calls are > required to make them useful. > * Some cloud providers allow all traffic by default (e.g. Digital Ocean, > RAX). > * It violates the end-to-end principle of the Internet to have a > middle-box meddling with traffic (the compute node in this case). > * Neutron cannot be trusted to do what it says it's doing with the > security groups API so users want to orchestrate firewalls directly on > their instances. > > > So this ultimately brings up two big questions. First, can we agree on a > set of defaults that is different than the one we have now; and, if so, how > could we possibly manage upgrades where this will completely change the > default filtering for users using the API? > > Second, would it be acceptable to make this operator configurable? This > would mean users could receive different default filtering as they moved > between clouds. > > > Cheers, > Kevin Benton > > __ > OpenStack Development Mailing 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] [api][neutron] question on putting an existing tag
Hi, Jay, an explanation would be appreciated as it seems 409 doesn't match HTTP RFC[1] [1] https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html Cédric/ZZelle On Fri, Feb 26, 2016 at 4:36 PM, Jay Pipes <jaypi...@gmail.com> wrote: > On 02/26/2016 09:02 AM, Akihiro Motoki wrote: > >> Hi API-WG, >> >> Neutron is implementing tag support for network resource [0]. >> The implementation follows 'Tags' guideline defined by API-WG [1]. >> I have a questions on the guideline. >> >> >> >> We can create a tag by PUT'ing an individual tag: >> What status code should be returned if a requested tag already exists? >> >> PUT /servers/1234567890/tags/qux >> >> The guideline defines 201 (+ Location header) on success. >> In the current neutron implementation proposed, 409 is returned >> when a requested tag already exists. >> > > 409 Conflict. > > Best, > -jay > > > __ > OpenStack Development Mailing 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] [kuryr] gerrit/git review problem error code 10061
Hi, An alternative solution is to use https instead of ssh to interact with gerrit: # It requires a "recent" gitreview git config gitreview.scheme https git config gitreview.port 443 git review -s It requires to define a http password in gerrit (settings > HTTP Password) Cédric/ZZelle@IRC On Wed, Nov 11, 2015 at 10:03 AM, Znoinski, Waldemar < waldemar.znoin...@intel.com> wrote: > Hi Baohua > > If you have a socks proxy to hand then you could check ‘tsocks’ - > http://tsocks.sourceforge.net/ or check your distro’s package manager. > > It’s quite ‘transparent’ proxying (over socks 4 or 5) of pretty much any > process you run with it, i.e.: > > > > tsocks scp -P29418 yangbao...@review.openstack.org:hooks/commit-msg > > .git\hooks\commit-msg" > > > > *From:* Baohua Yang [mailto:yangbao...@gmail.com] > *Sent:* Wednesday, November 11, 2015 2:15 AM > *To:* OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > *Subject:* Re: [openstack-dev] [kuryr] gerrit/git review problem error > code 10061 > > > > Thanks to all! > > It seems network connectivity problem. How sad again! :( > > i will try other ways. > > > > On Tue, Nov 10, 2015 at 12:52 AM, Jeremy Stanley <fu...@yuggoth.org> > wrote: > > On 2015-11-09 10:13:33 +0800 (+0800), Baohua Yang wrote: > > Anyone recently meet such problem after cloning the latest code > > from kuryr? Try proxy also, but not solved. > [...] > > The following command failed with exit code 1 > > "scp -P29418 yangbao...@review.openstack.org:hooks/commit-msg > > .git\hooks\commit-msg" > > --- > > FATAL: Unable to connect to relay host, errno=10061 > > ssh_exchange_identification: Connection closed by remote host > [...] > > I've checked our Gerrit SSH API authentication logs from the past 30 > days and find no record of any yangbaohua authenticating. Chances > are this is a broken local proxy or some sort of intercepting > firewall which is preventing your 29418/tcp connection from even > reaching review.openstack.org. > > If you use Telnet or NetCat to connect to port 29418 on > review.openstack.org directly, do you see an SSH banner starting > with a string like "SSH-2.0-GerritCodeReview_2.8.4-19-g4548330 > (SSHD-CORE-0.9.0.201311081)" or something else? > -- > Jeremy Stanley > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > > Best wishes! > Baohua > > -- > Intel Research and Development Ireland Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 > > This e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). Any review or distribution by others > is strictly prohibited. If you are not the intended recipient, please > contact the sender and delete all copies. > > > __ > OpenStack Development Mailing 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] [Neutron] Prepare for expiration bugs without activity
Hi everyone, As decided during last neutron meeting[1], we try to let Launchpad expire outdated bugs. The status of every bug without activity in last year has been set to Incomplete and their assignee/milestone unset in order to let Launchpad expire them in 60 days[2]. It gives us a 60-days window to "revive" expirable bugs[3] which are (sadly :)) still valid (by changing their status). Cedric/ZZelle@IRC PS: you can contact me if you have any questions [1] http://eavesdrop.openstack.org/meetings/networking/2015/networking.2015-10-06-14.00.txt [2] https://help.launchpad.net/Bugs/Expiry [3] https://bugs.launchpad.net/neutron/+expirable-bugs __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
Hi, SSLMiddleware takes into account a Header[1] to set wsgi.url_scheme which allows a proxy to provide the original protocol to Heat/Neutron/... Does that solution work in the HA Proxy case where there is one > terminating address for multiple backend servers? Because there is the > concern that this impacts not only the Location header, but the link > documents inside the responses which clients are expected to be able to > link.follow. This is an honest question, I don't know how the > oslo_middleware.ssl acts in these cases. And HA Proxy 1 to N mapping is > very common deployment model. > It ensures the protocol provided in headers will be used to generate correct Location Headers and links. BUT there are some limitations: * It doesn't work when the service itself acts as a proxy (typically nova image-list) * it doesn't work when you rewrite from https://://... to http://:/... because the information is not provided in the headers (except if you exploit a webob limitation) Cédric/ZZelle@IRC __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Consistent support for SSL termination proxies across all API services
Hi > Ok, how exactly does that work? Because it seems like > oslo_middleware.ssl is only changing the protocol if the proxy sets it. > > But the host in the urls will still be the individual host, which isn't > the proxy hostname/ip. Sorry if I'm being daft here, just want to > understand how that flow ends up working. > Host and X-Forwarded-Proto headers are provided by the proxy to the service. Host and X-Forwarded-Proto headers are either built by the proxy or forwarded (if there are many proxies). > Will that cover the case of webob's request.application_uri? If so I > think that covers the REST documents in at least Nova (one good data > point, and one that I know has been copied around). At least as far as > the protocol is concerned, it's still got a potential url issue. I let Julien answers :) > It also looks like there are new standards for Forwarded headers, so the > middleware should probably support those as well. > http://tools.ietf.org/html/rfc7239. > Good to know! I can update SSLMiddleware to handle it as the rfc uses the format: "Forwarded: proto=https" which is different from de facto standard (supported by SSLMiddleware): "X-Forwarded-Proto: https" Cédric __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] Feature Freeze Exception: shelving commands
Hi, I wanted to propose horizon-shelving-command[1][2] feature proposal for exception. This is a small feature based on existing pause/suspend command implementations. [1] https://blueprints.launchpad.net/horizon/+spec/horizon-shelving-command [2] https://review.openstack.org/220838 Cedric/ZZelle@IRC __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron]How to use external_net?
Hi, You need a router to bind internal network(s) with external network. Otherwise you cannot allocate a floating ip (on the external network) to VMs (on internal network(s)). The doc[1] explains how to do it. [1] http://docs.openstack.org/kilo/install-guide/install/apt/content/neutron_initial-tenant-network.html Cédric/ZZelle On Thu, Jul 30, 2015 at 1:08 PM, 于洁 16189...@qq.com wrote: Hi all, I find that if setting the value of router:external=True for a net(example: neutron net-update netID --router:external=True) Users in other tenants could allocate floating IP from this net(example: neutron floatingip-create netID). But how could this floating IP bind to a VM created by the user from other tenants? The network is unreachable. Or do I misunderstand the function? Thanks, Yu __ OpenStack Development Mailing 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] [Neutron] Proposing Cedric Brandily to Neutron Core Reviewer Team
Thanks Carl, Kevin, Assaf and everybody for your great support! Looking forward to helping out neutron growth! Cedric/ZZelle@IRC On Wed, Jul 22, 2015 at 7:02 PM, Miguel Lavalle mig...@mlavalle.com wrote: Congrats Cedric! On Wed, Jul 22, 2015 at 10:37 AM, Carl Baldwin c...@ecbaldwin.net wrote: It has been a week since this nomination. I'm pleased to confirm Cedric as a core reviewer for these areas of focus. We look forward to your continued contribution to the project! Carl On Wed, Jul 15, 2015 at 12:47 PM, Carl Baldwin c...@ecbaldwin.net wrote: As the Neutron L3 Lieutenant along with Kevin Benton for control plane, and Assaf Muller for testing, I would like to propose Cedric Brandily as a member of the Neutron core reviewer team under these areas of focus. Cedric has been a long time contributor to Neutron showing expertise particularly in these areas. His knowledge and involvement will be very important to the project. He is a trusted member of our community. He has been reviewing consistently [1][2] and community feedback that I've received indicates that he is a solid reviewer. Existing Neutron core reviewers from these areas of focus, please vote +1/-1 for the addition of Cedric to the team. Thanks! Carl Baldwin [1] https://review.openstack.org/#/q/reviewer:zzelle%2540gmail.com,n,z [2] http://stackalytics.com/report/contribution/neutron-group/90 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] when I run git review -s, it occur a error
Hi, Git review tries to download gerrit hook used to add automatically a Change-Id when missing. Old versions of git-review (1.24 iirc) badly supports http(s) protocols and use scp to download the hook. You have 2 options: * upgrade your git-review * or download manually the hook: mkdir .git/hooks wget https://review.openstack.org/tools/hooks/commit-msg -qO .git/hooks/commit-msg chmod +x .git/hooks/commit-msg Cédric On Wed, Jul 1, 2015 at 1:38 PM, 胡西宁 xin...@unitedstack.com wrote: hi everyone, when I run git review -s, it occur a error below, who can help me slove it, thanks # LANG=C LANGUAGE=C git review -v 2015-07-01 19:33:24.301828 Running: git log --color=never --oneline HEAD^1..HEAD 2015-07-01 19:33:24.306742 Running: git remote 2015-07-01 19:33:24.310573 Running: git branch -a --color=never 2015-07-01 19:33:24.315126 Running: git rev-parse --show-toplevel --git-dir 2015-07-01 19:33:24.318862 Running: git remote show -n gerrit Found origin Push URL: https://review.openstack.org/stackforge/python-tackerclient.git Fetching commit hook from: scp://review.openstack.org:None 2015-07-01 19:33:24.323647 Running: scp review.openstack.org:hooks/commit-msg .git/hooks/commit-msg Problems encountered installing commit-msg hook The following command failed with exit code 1 scp review.openstack.org:hooks/commit-msg .git/hooks/commit-msg --- .git/hooks/commit-msg: No such file or directory this my remote repo: #git remote -v gerrit https://review.openstack.org/stackforge/python-tackerclient.git (fetch) gerrit https://review.openstack.org/stackforge/python-tackerclient.git (push) originhttps://github.com/stackforge/python-tackerclient.git (fetch) originhttps://github.com/stackforge/python-tackerclient.git (push) thanks cinghu __ OpenStack Development Mailing 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] Looking for help getting git-review to work over https
Hi David, Ok, sudo python setup.py install without pbr install is not working behind an http proxy. Because you should use sudo -E python setup.py install to pass http(s)_proxy ernv variables. But even if you do so python setup.py install will try to install pbr WITHOUT taking into account proxy info :( Option 1: you wait for the 1.25 :) Option 2: you install manually pbr with pip or aptitude/yum and requests with aptitude/yum (otherwise requests will complain with https certificates) than On Fri, Jun 12, 2015 at 2:55 AM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-06-11 23:32:58 + (+), KARR, DAVID wrote: I managed to install pip, but I don’t understand what “pip install git-review” is doing. It doesn’t appear to be replacing the already installed git-review. `pip install git-review` installs the latest git-review release from pypi.python.org, but `pip install .` installs the source tree from your current working directory. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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] Looking for help getting git-review to work over https
Hi David, Following git config options are supported by git-review ( https://review.openstack.org/116035) git config --global gitreview.scheme https git config --global gitreview.port 443 BUT the feature was merged after 1.24 (it's highlighted by your git review -vs) so the feature is currently only available on the git-review master branch (which is quite stable, i use it every day). Cedric/ZZelle@irc On Thu, Jun 11, 2015 at 10:14 PM, KARR, DAVID dk0...@att.com wrote: I followed the instructions for installing and configuring corkscrew, similar to what you provided here. The result seems to indicate it did something, but the overall result is the same: 2015-06-11 13:07:25.866568 Running: git log --color=never --oneline HEAD^1..HEAD 2015-06-11 13:07:25.869309 Running: git remote 2015-06-11 13:07:25.872742 Running: git config --get gitreview.username No remote set, testing ssh:// dk0...@review.openstack.org:29418/openstack/horizon.git 2015-06-11 13:07:25.874869 Running: git push --dry-run ssh:// dk0...@review.openstack.org:29418/openstack/horizon.git --all The authenticity of host '[review.openstack.org]:29418 (no hostip for proxy command)' can't be established. RSA key fingerprint is 28:c6:42:b7:44:d2:48:64:c1:3f:31:d8:1b:6e:3b:63. Are you sure you want to continue connecting (yes/no)? yes ssh://dk0...@review.openstack.org:29418/openstack/horizon.git did not work. Could not connect to gerrit. Enter your gerrit username: --- *From:* Paul Michali [mailto:p...@michali.net] *Sent:* Thursday, June 11, 2015 11:09 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] Looking for help getting git-review to work over https Do you know if you have SSH access to the outside world through the firewall? Did you setup a proxy? I setup 'corkscrew' under Ubuntu. After installing, created a .ssh/config file with: Host review.openstack.org ProxyCommand corkscrew proxy-host 80 %h %p The proxy host is one that allows HTTP/HTTPS to outside world and corkscrew tunnels the SSH through to port 80. HTHs, PCM On Thu, Jun 11, 2015 at 12:44 PM KARR, DAVID dk0...@att.com wrote: Thanks for replying. % git review -vs 2015-06-11 09:30:38.396076 Running: git log --color=never --oneline HEAD^1..HEAD 2015-06-11 09:30:38.399021 Running: git remote 2015-06-11 09:30:38.401033 Running: git config --get gitreview.username No remote set, testing ssh:// dk0...@review.openstack.org:29418/openstack/horizon.git 2015-06-11 09:30:38.402988 Running: git push --dry-run ssh:// dk0...@review.openstack.org:29418/openstack/horizon.git --all ssh://dk0...@review.openstack.org:29418/openstack/horizon.git did not work. Could not connect to gerrit. Enter your gerrit username: This output is interesting, because I followed the instructions to set the scheme and port to https and 443, which can be seen from: % git config --global -l user.name=David Karr user.email=dk0...@att.com gitreview.scheme=https gitreview.port=443 Concerning the question ‘Do you have gerrit remote already configured?’, I guess I’d have to say I don’t know. I’ve followed instructions for setting up my pub key, but I’m not sure exactly what is entailed in “gerrit remote”. I can get to https://review.openstack.org/ from my browser and from the command line with curl. The “ls-remote” command returns without error (or any other output). *From:* Yuriy Taraday [mailto:yorik@gmail.com] *Sent:* Thursday, June 11, 2015 9:19 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] Looking for help getting git-review to work over https On Thu, Jun 11, 2015, 18:09 KARR, DAVID dk0...@att.com wrote: I could use some help with setting up git-review in a slightly unfriendly firewall situation. I'm trying to set up git-review on my CentOS7 VM, and our firewall blocks the non-standard ssh port. I'm following the instructions at http://docs.openstack.org/infra/manual/developers.html#accessing-gerrit-over-https , for configuring git-review to use https on port 443, but this still isn't working (times out with Could not connect to gerrit). I've confirmed that I can reach other external sites on port 443. Can someone give me a hand with this? Hello. - Can you please post all output from git review -vs? - Do you have gerrit remote already configured? - Do you have access to https://review.openstack.org/ from your browser? - Can you access it from command line (via curl -I https://review.openstack.org/; for example)? - Does git ls-remote https://review.openstack.org/openstack/nova /dev/null produce and error? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org
Re: [openstack-dev] Looking for help getting git-review to work over https
Indeed, the doc[1] is unclear git-review can be installed using: python setup.py install or pip install . [1] http://docs.openstack.org/infra/manual/developers.html#accessing-gerrit-over-https On Thu, Jun 11, 2015 at 11:16 PM, KARR, DAVID dk0...@att.com wrote: I see. I would guess a footnote on the instructions about this would be useful. Is https://github.com/openstack-infra/git-review the proper location to get the buildable source? I don’t see any obvious build instructions there. *From:* ZZelle [mailto:zze...@gmail.com] *Sent:* Thursday, June 11, 2015 2:01 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] Looking for help getting git-review to work over https Hi David, Following git config options are supported by git-review ( https://review.openstack.org/116035) git config --global gitreview.scheme https git config --global gitreview.port 443 BUT the feature was merged after 1.24 (it's highlighted by your git review -vs) so the feature is currently only available on the git-review master branch (which is quite stable, i use it every day). Cedric/ZZelle@irc On Thu, Jun 11, 2015 at 10:14 PM, KARR, DAVID dk0...@att.com wrote: I followed the instructions for installing and configuring corkscrew, similar to what you provided here. The result seems to indicate it did something, but the overall result is the same: 2015-06-11 13:07:25.866568 Running: git log --color=never --oneline HEAD^1..HEAD 2015-06-11 13:07:25.869309 Running: git remote 2015-06-11 13:07:25.872742 Running: git config --get gitreview.username No remote set, testing ssh:// dk0...@review.openstack.org:29418/openstack/horizon.git 2015-06-11 13:07:25.874869 Running: git push --dry-run ssh:// dk0...@review.openstack.org:29418/openstack/horizon.git --all The authenticity of host '[review.openstack.org]:29418 (no hostip for proxy command)' can't be established. RSA key fingerprint is 28:c6:42:b7:44:d2:48:64:c1:3f:31:d8:1b:6e:3b:63. Are you sure you want to continue connecting (yes/no)? yes ssh://dk0...@review.openstack.org:29418/openstack/horizon.git did not work. Could not connect to gerrit. Enter your gerrit username: --- *From:* Paul Michali [mailto:p...@michali.net] *Sent:* Thursday, June 11, 2015 11:09 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] Looking for help getting git-review to work over https Do you know if you have SSH access to the outside world through the firewall? Did you setup a proxy? I setup 'corkscrew' under Ubuntu. After installing, created a .ssh/config file with: Host review.openstack.org ProxyCommand corkscrew proxy-host 80 %h %p The proxy host is one that allows HTTP/HTTPS to outside world and corkscrew tunnels the SSH through to port 80. HTHs, PCM On Thu, Jun 11, 2015 at 12:44 PM KARR, DAVID dk0...@att.com wrote: Thanks for replying. % git review -vs 2015-06-11 09:30:38.396076 Running: git log --color=never --oneline HEAD^1..HEAD 2015-06-11 09:30:38.399021 Running: git remote 2015-06-11 09:30:38.401033 Running: git config --get gitreview.username No remote set, testing ssh:// dk0...@review.openstack.org:29418/openstack/horizon.git 2015-06-11 09:30:38.402988 Running: git push --dry-run ssh:// dk0...@review.openstack.org:29418/openstack/horizon.git --all ssh://dk0...@review.openstack.org:29418/openstack/horizon.git did not work. Could not connect to gerrit. Enter your gerrit username: This output is interesting, because I followed the instructions to set the scheme and port to https and 443, which can be seen from: % git config --global -l user.name=David Karr user.email=dk0...@att.com gitreview.scheme=https gitreview.port=443 Concerning the question ‘Do you have gerrit remote already configured?’, I guess I’d have to say I don’t know. I’ve followed instructions for setting up my pub key, but I’m not sure exactly what is entailed in “gerrit remote”. I can get to https://review.openstack.org/ from my browser and from the command line with curl. The “ls-remote” command returns without error (or any other output). *From:* Yuriy Taraday [mailto:yorik@gmail.com] *Sent:* Thursday, June 11, 2015 9:19 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] Looking for help getting git-review to work over https On Thu, Jun 11, 2015, 18:09 KARR, DAVID dk0...@att.com wrote: I could use some help with setting up git-review in a slightly unfriendly firewall situation. I'm trying to set up git-review on my CentOS7 VM, and our firewall blocks the non-standard ssh port. I'm following the instructions at http://docs.openstack.org/infra/manual/developers.html#accessing-gerrit-over-https , for configuring git-review to use https on port 443
Re: [openstack-dev] Why do we drop branches? (WAS: Re: Targeting icehouse-eol?)
We can do the opposite to avoid more and more ACLs: ALLOW push on some specific stable branches [access refs/heads/stable/kilo] push = allow group ***-stable-maint [access refs/heads/stable/juno] push = allow group ***-stable-maint BLOCK push on others stable branches [access refs/heads/stable/juno] push = block group Anonymous Users Cedric/ZZelle@IRC On Thu, Jun 4, 2015 at 6:15 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-06-04 16:23:12 +0200 (+0200), Ihar Hrachyshka wrote: Why do we even drop stable branches? If anything, it introduces unneeded problems to those who have their scripts/cookbooks set to chase those branches. They would need to switch to eol tag. Why not just leaving them sitting there, marked read only? It becomes especially important now that we say that stable HEAD *is* a stable release. It's doable, but we'll need ACL changes applied to every project participating in this release model to reject new change submissions and prevent anyone from approving them on every branch which reaches its EOL date. These ACLs will also grow longer and longer over time as we need to add new sections for each EOL branch. Also, it seems to me like a feature if downstream consumers have to take notice and explicitly adjust their tooling to intentionally continue deploying a release for which we no longer provide support and security updates. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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] Why do we drop branches? (WAS: Re: Targeting icehouse-eol?)
argh BLOCK push on others stable branches [access refs/heads/stable/*] push = block group Anonymous Users On Thu, Jun 4, 2015 at 6:34 PM, ZZelle zze...@gmail.com wrote: We can do the opposite to avoid more and more ACLs: ALLOW push on some specific stable branches [access refs/heads/stable/kilo] push = allow group ***-stable-maint [access refs/heads/stable/juno] push = allow group ***-stable-maint BLOCK push on others stable branches [access refs/heads/stable/juno] push = block group Anonymous Users Cedric/ZZelle@IRC On Thu, Jun 4, 2015 at 6:15 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-06-04 16:23:12 +0200 (+0200), Ihar Hrachyshka wrote: Why do we even drop stable branches? If anything, it introduces unneeded problems to those who have their scripts/cookbooks set to chase those branches. They would need to switch to eol tag. Why not just leaving them sitting there, marked read only? It becomes especially important now that we say that stable HEAD *is* a stable release. It's doable, but we'll need ACL changes applied to every project participating in this release model to reject new change submissions and prevent anyone from approving them on every branch which reaches its EOL date. These ACLs will also grow longer and longer over time as we need to add new sections for each EOL branch. Also, it seems to me like a feature if downstream consumers have to take notice and explicitly adjust their tooling to intentionally continue deploying a release for which we no longer provide support and security updates. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Functional tests coverage
Hi Serge,
... tox -e cover is not really efficient for functional tests ...
You can start with dhcp, as there is already a base (abandoned change[1]
from Marios).
Regards,
Cedric/ZZelle
[1] https://review.openstack.org/136834
On Wed, Jun 3, 2015 at 3:21 PM, Andreas Jaeger a...@suse.com wrote:
On 06/03/2015 03:13 PM, Sergey Belous wrote:
Hi All,
I want to write the functional tests for Neutron. But the first I want
to know the current coverage. How to measure test coverage of code?
Where to look and what to start?
tox -e cover should run the coverage tests of neutron,
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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers
Hi, HA on DHCP is done by setting dhcp_agents_per_network = 2, so production deploiements should set dhcp_agents_per_network = 2. Regards, Cédric/ZZelle On Tue, May 26, 2015 at 12:24 PM, neil.jer...@metaswitch.com wrote: How about retaining --dhcp-authoritative when dhcp_agents_per_network = 1? I would guess that that is the 90% case. I suppose that would require passing new information from the Neutron server to the DHCP agents; but maybe that's feasible, and it feels like the right thing to do. Also, what are the use cases for dhcp_agents_per_network = 2 ? Regards, Neil *From: *Doug Wiegley *Sent: *Tuesday, 26 May 2015 04:14 *To: *OpenStack Development Mailing List (not for usage questions) *Reply To: *OpenStack Development Mailing List (not for usage questions) *Subject: *Re: [openstack-dev] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers After a brief IRC conversation with Kevin, he pointed out that we already don't allow any other ports on the subnet to send DHCP replies, so NAKs are completely unnecessary. I'd be fine just filtering them out for now. Thanks, doug On May 25, 2015, at 7:54 PM, Kevin Benton blak...@gmail.com wrote: Here is the description of the behavior for --dhcp-authoritative from the dnsmasq page. [1] Should be set when dnsmasq is definitely the only DHCP server on a network. For DHCPv4, it changes the behaviour from strict RFC compliance so that DHCP requests on unknown leases from unknown hosts are not ignored. This allows new hosts to get a lease without a tedious timeout under all circumstances. It also allows dnsmasq to rebuild its lease database without each client needing to reacquire a lease, if the database is lost. For DHCPv6 it sets the priority in replies to 255 (the maximum) instead of 0 (the minimum). As far as I understand it, the original intent of the patch that caused the issue was to fix that refusal to answer lease renewals after a restart. So it wasn't added to get NAKs, it was added to make it respond to renewals before they timeout. 1. http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html On Mon, May 25, 2015 at 7:44 PM, Doug Wiegley doug...@parksidesoftware.com wrote: Option 4, turn off authoritative if we don't want NAK's? doug On May 25, 2015, at 7:35 PM, Kevin Benton blak...@gmail.com wrote: Hi, A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has caused DHCPNAK messages when multiple agents are scheduled to a network [2]. This was back-ported to Icehouse and Juno so we need a fix that is compatible with both of them. I have two fixes for this so far and a third alternative if we don't like those. The first is hacky, but it's only a few-line change.[3] It adds an iptables rule that just stops the DHCPNAKs from making it to the client. This is clean to back-port but it doesn't protect clients that have filtering disabled (e.g. bare metal). The second persists the DHCP leases to a database.[4] The downside to this was always that being rescheduled to another agent would mean no entries in the lease file. This approach adds a work-around to generate an initial fake lease file based on all of the ports in the network. A third approach that I don't have a patch pushed for yet is very similar to the second. When dnsmasq is in the leasefile-ro mode, it will call the script passed to --dhcp-script to get a list of leases to start with. This script would be built with the same logic as the second one. The only difference between the second approach is that dnsmasq wouldn't persist leases to a database. I'm looking for feedback on how we want to go forward with this in a back-port friendly manner. Cheers, Kevin Benton 1. https://review.openstack.org/#/q/Ieff0236670c1403b5d79ad8e50d7574c1b694e34,n,z 2. https://bugs.launchpad.net/neutron/+bug/1457900 3. https://review.openstack.org/#/c/185332/ 4. https://review.openstack.org/#/c/185486/ -- Kevin Benton __ OpenStack Development Mailing 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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] Fail to launch VM due to maximum number of ports exceeded
Hi Danny, Port quota includes compute ports (for vms) + network ports (for dhcps/routers). You seems to have 40 compute ports + 5 networks x 2 (1 port for the dhcp and 1 port for the router) == 50 ports. Cedric ZZelle@IRC On Sun, Dec 21, 2014 at 5:02 AM, Timur Nurlygayanov tnurlygaya...@mirantis.com wrote: Hi Danny, what about the global ports count and quotas? On Sun, Dec 21, 2014 at 1:32 AM, Danny Choi (dannchoi) dannc...@cisco.com wrote: Hi, The default quota for port is 50. +--++-+ localadmin@qa4:~/devstack$ neutron quota-show --tenant-id 1b2e5efaeeeb46f2922849b483f09ec1 +-+---+ | Field | Value | +-+---+ | floatingip | 50| | network | 10| | port| 50| 50 | router | 10| | security_group | 10| | security_group_rule | 100 | | subnet | 10| +-+---+ Total number of ports used so far is 40. localadmin@qa4:~/devstack$ nova list +--+--+++-+---+ | ID | Name | Status | Task State | Power State | Networks | +--+--+++-+---+ | 595940bd-3fb1-4ad3-8cc0-29329b464471 | VM-1 | ACTIVE | - | Running | private_net30=30.0.0.44 | | 192ce36d-bc76-427a-a374-1f8e8933938f | VM-2 | ACTIVE | - | Running | private_net30=30.0.0.45 | | 10ad850e-ed9d-42d9-8743-b8eda4107edc | cirros--10ad850e-ed9d-42d9-8743-b8eda4107edc | ACTIVE | - | Running | private_net20=20.0.0.38; private=10.0.0.52 | | 18209b40-09e7-4718-b04f-40a01a8e5993 | cirros--18209b40-09e7-4718-b04f-40a01a8e5993 | ACTIVE | - | Running | private_net20=20.0.0.40; private=10.0.0.54 | | 1ededa1e-c820-4915-adf2-4be8eedaf012 | cirros--1ededa1e-c820-4915-adf2-4be8eedaf012 | ACTIVE | - | Running | private_net20=20.0.0.41; private=10.0.0.55 | | 3688262e-d00f-4263-91a7-785c40f4ae0f | cirros--3688262e-d00f-4263-91a7-785c40f4ae0f | ACTIVE | - | Running | private_net20=20.0.0.34; private=10.0.0.49 | | 4620663f-e6e0-4af2-84c0-6108279cbbed | cirros--4620663f-e6e0-4af2-84c0-6108279cbbed | ACTIVE | - | Running | private_net20=20.0.0.37; private=10.0.0.51 | | 8f8252a3-fa23-47fc-8b32-7f7328ecfba2 | cirros--8f8252a3-fa23-47fc-8b32-7f7328ecfba2 | ACTIVE | - | Running | private_net20=20.0.0.39; private=10.0.0.53 | | a228f33b-0388-464e-af49-b55af9601f56 | cirros--a228f33b-0388-464e-af49-b55af9601f56 | ACTIVE | - | Running | private_net20=20.0.0.42; private=10.0.0.56 | | def5a255-0c9d-4df0-af02-3944bf5af2db | cirros--def5a255-0c9d-4df0-af02-3944bf5af2db | ACTIVE | - | Running | private_net20=20.0.0.36; private=10.0.0.50 | | e1470813-bf4c-4989-9a11-62da47a5c4b4 | cirros--e1470813-bf4c-4989-9a11-62da47a5c4b4 | ACTIVE | - | Running | private_net20=20.0.0.33; private=10.0.0.48 | | f63390fa-2169-45c0-bb02-e42633a08b8f | cirros--f63390fa-2169-45c0-bb02-e42633a08b8f | ACTIVE | - | Running | private_net20=20.0.0.35; private=10.0.0.47 | | 2c34956d-4bf9-45e5-a9de-84d3095ee719 | vm--2c34956d-4bf9-45e5-a9de-84d3095ee719 | ACTIVE | - | Running | private_net30=30.0.0.39; private_net50=50.0.0.29; private_net40=40.0.0.29 | | 680c55f5-527b-49e3-847c-7794e1f8e7a8 | vm--680c55f5-527b-49e3-847c-7794e1f8e7a8 | ACTIVE | - | Running | private_net30=30.0.0.41; private_net50=50.0.0.30; private_net40=40.0.0.31 | | ade4c14b-baf7-4e57-948e-095689f73ce3 | vm--ade4c14b-baf7-4e57-948e-095689f73ce3 | ACTIVE | - | Running | private_net30=30.0.0.43; private_net50=50.0.0.32; private_net40=40.0.0.33 | | c91e426a-ed68-4659-89f6-df6d1154bb16 | vm--c91e426a-ed68-4659-89f6-df6d1154bb16 | ACTIVE | - | Running | private_net30=30.0.0.42; private_net50=50.0.0.33; private_net40=40.0.0.32 | | cedd9984-79f0-46b3-897d-b301cfa74a1a | vm--cedd9984-79f0-46b3-897d-b301cfa74a1a | ACTIVE | - | Running | private_net30=30.0.0.40; private_net50=50.0.0.31; private_net40=40.0.0.30 | | ec83e53f-556f-4e66-ab85-15a9e1ba9d28 | vm--ec83e53f
Re: [openstack-dev] [Neutron] LeastNetwork scheduling for DHCP
Hi, iiuc, It seems [1][3] share exactly the same objective and implementation intention: - define an common abstract dhcp scheduler class - define a dhcp LeastNetworkScheduler [2] proposes to - define a dhcp LeastVmScheduler (networks are scheduled on the dhcp agent supporting the least vms (=ports?)) So i am not sure we need an umbrella spec as [1][3] can be merged in [1] (the older wins?) and [2] can become a daughter spec or can be merged with previous spec? Cedric, ZZelle@IRC [1] https://review.openstack.org/104587 [2] https://review.openstack.org/111210 [3] https://review.openstack.org/130912 On Thu, Nov 6, 2014 at 4:39 PM, Narasimhan, Vivekanandan vivekanandan.narasim...@hp.com wrote: Hi Neutron Stackers, There is an interest among vendors to bring Least Networks scheduling for DHCP into Openstack Neutron. Currently there are the following blueprints lying there, all of them trying to address this issue: https://review.openstack.org/111210 https://review.openstack.org/#/c/130912/ https://review.openstack.org/104587 We are trying to pull together all these BPs as one Umbrella BP, on which we can pour volunteers from every side, to clear out this BP itself as initial step. So we would like to collaborate, to plan BP approval for these. Please respond if you are interested. -- Thanks, Vivek ___ 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] [Infra][all] Synchronizing local Git and Gerrit repositories
Hi Ondrej, Could you clarify your needs? If you allow your devs to commit code on your local gerrit, then your repo will differ from OpenStack one and you might have merge troubles when you will resync your repo with OpenStack one How will you handle them? Cédric/ZZelle On Mon, Oct 27, 2014 at 12:24 PM, Ondrej Wisniewski ondrej.wisniew...@dektech.com.au wrote: Hi Riccardo thanks for pointers you provided. I had a look at the Gerrit replication feature and the description says: *Gerrit can automatically push any changes it makes to its managed Git repositories to another system.* What I need would be exactly the opposite. I need to update the Gerrit managed Git repository with the upstream community Git repository. How would I go about that? What I tried was defining the community repository as remote origin and then do git remote update. This updates the remote references but doesn't update the local branches. Thanks, Ondrej On 10/24/2014 06:56 PM, Ricardo Carrillo Cruz wrote: Hi Ondrej The replication between Gerrit and git mirrors is done by the Gerrit replication mechanism. If you look at this line in the gerrit manifest: http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/gerrit/manifests/init.pp#n255 you will see that it deploys a 'replication.config' file based on template: http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/gerrit/templates/replication.config.erb You can find more information about how Gerrit replication works here: http://gerrit.googlecode.com/svn/documentation/2.0/config-replication.html HTH Regards 2014-10-24 18:25 GMT+02:00 Ondrej Wisniewski ondrej.wisniew...@dektech.com.au: Hi, I am trying to set up an OpenStack development workflow in our company. We have an internal Git repository mirror of all OpenStack projects we are working on. It is periodically updated from the upstream OpenStack community servers. This is used to share the code among developers. Furthermore I have set up a Gerrit server for the internal code review. The Gerrit server also works with repository mirrors of the community repositories which should be updated periodically. Or at least that's the idea. I ran into lots of problems and couldn't find a good way of synchronizing the developer mirrors with the Gerrit repositories. So to cut a long story short, here are my questions: How is the synchronization of the OpenStack community Git repositories and the Gerrit server done? How can I import an OpenStack project into my Gerrit system from my local Git mirror and keep both synchronized (at least the master branch) ? I would be really appreciate if someone could shed some light on this. Thanks, Ondrej ___ 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] China blocking access to OpenStack git review push
Hi, You can use git-credentials-cache or git-credentials-store to persist your password: # cache[1]: safer but cleaned after timeout or reboot git config --global credential.https://review.openstack.org..helper=cache --timeout XXX # or # store[2]: permanent but less safer, stored in a plain file ... no clean git config --global credential.https://review.openstack.org.helper=store Cedric, ZZelle@ IRC [1]http://git-scm.com/docs/git-credential-cache [2]http://git-scm.com/docs/git-credential-store On Mon, Sep 15, 2014 at 5:31 AM, Qiming Teng teng...@linux.vnet.ibm.com wrote: As an alternative to pushing via ssh you can push via https over port 443 which may bypass this port blockage. Both latest git review and the version of gerrit that we are running support this. The first step is to generate a gerrit http password, this will be used to authenticate against Gerrit. Go to https://review.openstack.org/#/settings/http-password and generate a password there (note this is independent of your launchpad openid password). Next step is to get some code clone it from eg https://git.openstack.org/openstack-dev/sandbox. Now I am sure there is a better way to have git-review do this for you with config overrides somewhere but we need to add a git remote in that repo called 'gerrit'. By default all of our .gitreview files set this up for ssh so we will manually add one. `git remote add gerrit https://usern...@review.openstack.org/openstack-dev/sandbox`. Finally run `git review -s` to get the needed commit hook and now you are ready to push code with `git review` as you normally would. Note when git review asks for a password it will want the password we generated in the first step. I am pretty sure this is can be made easier and the manual git remote step is not required if you set up some overrides in git(review) config files. Maybe the folks that added https support for git review can fill us in. Clark Thanks, Clark. The HTTPS way worked for me. There is one additional inconvenience, though. Everytime I do 'git review', I have to input the password twice, and the password has to be input using a GNOME window instead from command line (SSH'ed). Are you aware of 1) a place to save this password so that I don't have to input it every time? 2) a configuration option that allow me to input password from remote console? I'm not considering a X11 forward at the moment. Thanks. Regards, - Qiming ___ 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] [neutron][ml2] Mech driver as out-of-tree add-on
Hi, The important thing to understand is how to integrate with neutron through stevedore/entrypoints: https://github.com/dave-tucker/odl-neutron-drivers/blob/master/setup.cfg#L32-L34 Cedric On Wed, Aug 13, 2014 at 12:17 PM, Dave Tucker d...@dtucker.co.uk wrote: I've been working on this for OpenDaylight https://github.com/dave-tucker/odl-neutron-drivers This seems to work for me (tested Devstack w/ML2) but YMMV. -- Dave ___ 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] [git-review] Supporting development in local branches
Hi, I like the idea ... with complex change, it could useful for the understanding to split it into smaller changes during development. Do we need to expose such feature under git review? we could define a new subcommand? git reviewflow? Cédric, ZZelle@IRC On Tue, Aug 5, 2014 at 4:49 PM, Ryan Brown rybr...@redhat.com wrote: On 08/05/2014 09:27 AM, Sylvain Bauza wrote: Le 05/08/2014 13:06, Ryan Brown a écrit : -1 to this as git-review default behaviour. Ideally, branches should be identical in between Gerrit and local Git. Probably not as default behaviour (people who don't want that workflow would be driven mad!), but I think enough folks would want it that it should be available as an option. I can understand some exceptions where developers want to work on intermediate commits and squash them before updating Gerrit, but in that case, I can't see why it needs to be kept locally. If a new patchset has to be done on patch A, then the local branch can be rebased interactively on last master, edit patch A by doing an intermediate patch, then squash the change, and pick the later patches (B to E) That said, I can also understand that developers work their way, and so could dislike squashing commits, hence my proposal to have a --no-squash option when uploading, but use with caution (for a single branch, how many dependencies are outdated in Gerrit because developers work on separate branches for each single commit while they could work locally on a single branch ? I can't iimagine how often errors could happen if we don't force by default to squash commits before sending them to Gerrit) -Sylvain Cheers, ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I am well aware this may be straying into feature creep territory, and it wouldn't be terrible if this weren't implemented. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ 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] [Neutron] Route cannot be deleted
Hi,
According to the first error message, the subnet you try to unbind is used
in router routes, you can see current router routes using:
*neutron router-update **2f16d846-b6aa-43a3-adbe-**7f91a1389b7f*
you need to update them before unbind:
* neutron router-update **2f16d846-b6aa-43a3-adbe-*
*7f91a1389b7f --routes type=dict list=true destination=...,nexthop=...
[destination=...,nexthop=...[...]]*
or clear router routes:
* neutron router-update 2f16d846-b6aa-43a3-adbe-7f91a1389b7f --routes
action=clear*
And finally retry to unbind the subnet.
Cédric,
ZZelle@IRC
On Sat, Aug 2, 2014 at 9:56 AM, Sayali Lunkad sayali.92...@gmail.com
wrote:
Hi,
I am facing trouble deleting a router from my openstack deployment.
I have tried the following commands on the *controller node* and pasted
the output.
*neutron router-interface-delete* 2f16d846-b6aa-43a3-adbe-7f91a1389b7f
962b8364-a2b4-46cc-95be-28cbab62b8c2
409-{u'NeutronError': {u'message': u'Router interface for subnet
962b8364-a2b4-46cc-95be-28cbab62b8c2 on router
2f16d846-b6aa-43a3-adbe-7f91a1389b7f cannot be deleted, as it is required
by one or more routes.', u'type': u'RouterInterfaceInUseByRoute',
u'detail': u''}}
*neutron port-delete* ec1aac66-481d-488e-860b-53b88d950ac7
409-{u'NeutronError': {u'message': u'Port
ec1aac66-481d-488e-860b-53b88d950ac7 has owner network:router_interface and
therefore cannot be deleted directly via the port API.', u'type':
u'L3PortInUse', u'detail': u''}}
*neutron router-delete* 2f16d846-b6aa-43a3-adbe-7f91a1389b7f
409-{u'NeutronError': {u'message': u'Router
2f16d846-b6aa-43a3-adbe-7f91a1389b7f still has active ports', u'type':
u'RouterInUse', u'detail': u''}}
*neutron l3-agent-router-remove* 7a977e23-767f-418e-8429-651c4232548c
2f16d846-b6aa-43a3-adbe-7f91a1389b7f
This removes the router from the l3 agent and attaches it to another one
as seen below.
*neutron l3-agent-list-hosting-router*
2f16d846-b6aa-43a3-adbe-7f91a1389b7f
+--+--++---+
| id | host |
admin_state_up | alive |
+--+--++---+
| 96e1371a-be03-42ed-8141-3b0027d3a82f | alln01-1-csx-net-004 |
True | :-) |
+--+--++---+
I have also run the commands below on the *network node* which worked
fine.
*ip netns delete* qrouter-2f16d846-b6aa-43a3-adbe-7f91a1389b7f
*ovs-vsctl del-port* br-int qr-ec1aac66-48
Could someone please tell me what can be done to delete the router or is
this some bug I am hitting.
Thanks,
Sayali.
___
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] [Neutron] Route cannot be deleted
First command is of course:
* neutron router-show **2f16d846-b6aa-43a3-adbe-*
*7f91a1389b7f*
not
* neutron router-update **2f16d846-b6aa-43a3-adbe-**7f91a1389b7f*
On Sat, Aug 2, 2014 at 11:54 AM, ZZelle zze...@gmail.com wrote:
Hi,
According to the first error message, the subnet you try to unbind is used
in router routes, you can see current router routes using:
*neutron router-update **2f16d846-b6aa-43a3-adbe-**7f91a1389b7f*
you need to update them before unbind:
* neutron router-update **2f16d846-b6aa-43a3-adbe-*
*7f91a1389b7f --routes type=dict list=true destination=...,nexthop=...
[destination=...,nexthop=...[...]] *
or clear router routes:
* neutron router-update 2f16d846-b6aa-43a3-adbe-7f91a1389b7f --routes
action=clear *
And finally retry to unbind the subnet.
Cédric,
ZZelle@IRC
On Sat, Aug 2, 2014 at 9:56 AM, Sayali Lunkad sayali.92...@gmail.com
wrote:
Hi,
I am facing trouble deleting a router from my openstack deployment.
I have tried the following commands on the *controller node* and pasted
the output.
*neutron router-interface-delete* 2f16d846-b6aa-43a3-adbe-7f91a1389b7f
962b8364-a2b4-46cc-95be-28cbab62b8c2
409-{u'NeutronError': {u'message': u'Router interface for subnet
962b8364-a2b4-46cc-95be-28cbab62b8c2 on router
2f16d846-b6aa-43a3-adbe-7f91a1389b7f cannot be deleted, as it is required
by one or more routes.', u'type': u'RouterInterfaceInUseByRoute',
u'detail': u''}}
*neutron port-delete* ec1aac66-481d-488e-860b-53b88d950ac7
409-{u'NeutronError': {u'message': u'Port
ec1aac66-481d-488e-860b-53b88d950ac7 has owner network:router_interface and
therefore cannot be deleted directly via the port API.', u'type':
u'L3PortInUse', u'detail': u''}}
*neutron router-delete* 2f16d846-b6aa-43a3-adbe-7f91a1389b7f
409-{u'NeutronError': {u'message': u'Router
2f16d846-b6aa-43a3-adbe-7f91a1389b7f still has active ports', u'type':
u'RouterInUse', u'detail': u''}}
*neutron l3-agent-router-remove* 7a977e23-767f-418e-8429-651c4232548c
2f16d846-b6aa-43a3-adbe-7f91a1389b7f
This removes the router from the l3 agent and attaches it to another one
as seen below.
*neutron l3-agent-list-hosting-router*
2f16d846-b6aa-43a3-adbe-7f91a1389b7f
+--+--++---+
| id | host |
admin_state_up | alive |
+--+--++---+
| 96e1371a-be03-42ed-8141-3b0027d3a82f | alln01-1-csx-net-004 |
True | :-) |
+--+--++---+
I have also run the commands below on the *network node* which worked
fine.
*ip netns delete* qrouter-2f16d846-b6aa-43a3-adbe-7f91a1389b7f
*ovs-vsctl del-port* br-int qr-ec1aac66-48
Could someone please tell me what can be done to delete the router or is
this some bug I am hitting.
Thanks,
Sayali.
___
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] [neutron] Cross-server locking for neutron server
Hello, I stop to improve vxlan population and remove SELECT FOR UPDATE[1] because i am not sure the current approach is the right approach to handle vxlan/gre tenant pools: 1- Do we really to populate vxlan/gre tenant pools? The neutron-server could also choose randomly an vxlan vni in vni_ranges and tries to allocate it and retries until allocate success. I did not verify but mac address allocation should use the same principle? It is efficient if used_vnis is small enough (50%) compared to vni_ranges size. I am about to propose an update of neutron.plugins.ml2.drivers.helpers[2] in this direction. 2- Do we need to populate/update vxlan/gre tenant pools on neutron-server restart? A specific command could populate/update them (neutron-db-manage populate / neutron-db-populate) Any thoughts? [1] https://review.openstack.org/#/c/101982 [2] https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/helpers.py Cedric ZZelle@IRC On Wed, Jul 30, 2014 at 7:30 PM, Jay Pipes jaypi...@gmail.com wrote: On 07/30/2014 10:05 AM, Kevin Benton wrote: i.e. 'optimistic locking' as opposed to the 'pessimistic locking' referenced in the 3rd link of the email starting the thread. No, there's no locking. On Wed, Jul 30, 2014 at 9:55 AM, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: On 07/30/2014 09:48 AM, Doug Wiegley wrote: I'd have to look at the Neutron code, but I suspect that a simple strategy of issuing the UPDATE SQL statement with a WHERE condition that I¹m assuming the locking is for serializing code, whereas for what you describe above, is there some reason we wouldn¹t just use a transaction? Because you can't do a transaction from two different threads... The compare and update strategy is for avoiding the use of SELECT FOR UPDATE. Best, -jay _ OpenStack-dev mailing list OpenStack-dev@lists.openstack.__org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ 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] [Neutron] One performance issue about VXLAN pool initiation
Hi everyone, A new change (https://review.openstack.org/101982) has been proposed to improve vxlan pool initiation with an improvement on delete of obsolete unallocated vnis using a unique delete SQL command. I've tested performance with the following (delete only) scenario: vxlan range is changed from 0:10 to 5:10. The scenario code is available here: http://paste.openstack.org/show/84882 50k vnis to deletePostgresql MySQL Sqlite current code 6,0 5,5 5,1 proposed code 3,2 3,3 3,2 The gain is from 40% to 50%. Raw results: http://paste.openstack.org/show/84890 On Mon, Jun 9, 2014 at 3:38 PM, Eugene Nikanorov enikano...@mirantis.com wrote: Mike, Thanks a lot for your response! Some comments: There's some in-Python filtering following it which does not seem necessary; the alloc.vxlan_vni not in vxlan_vnis phrase could just as well be a SQL NOT IN expression. There we have to do specific set intersection between configured ranges and existing allocation. That could be done in sql, but that certainly would lead to a huge sql query text as full vxlan range could consist of 16 millions of ids. The synchronize_session=fetch is certainly a huge part of the time spent here You've actually made a good point about synchronize_session=fetch which was obviously misused by me. It seems to save up to 40% of plain deleting time. I've fixed that and get some speedup with deletes for both mysql and postgress that reduced difference between chunked/non-chunked version: 50k vnis to add/deletePg adding vnisPg deleting vnis Pg TotalMysql adding vnis Mysql deleting vnisMysql totalnon-chunked sql 221537 151530 chuked in 10020 133314 1428 Results of chunked and non-chunked version look closer, but gap increases with vni range size (based on few tests of 150k vni range) So I'm going to fix chunked version that is on review now. If you think that the benefit doesn't worth complexity - please let me know. Thanks, Eugene. On Mon, Jun 9, 2014 at 1:33 AM, Mike Bayer mba...@redhat.com wrote: On Jun 7, 2014, at 4:38 PM, Eugene Nikanorov enikano...@mirantis.com wrote: Hi folks, There was a small discussion about the better way of doing sql operations for vni synchronization with the config. Initial proposal was to handle those in chunks. Carl also suggested to issue a single sql query. I've did some testing with my sql and postgress. I've tested the following scenario: vxlan range is changed from 5:15 to 0:10 and vice versa. That involves adding and deleting 5 vni in each test. Here are the numbers: 50k vnis to add/deletePg adding vnisPg deleting vnis Pg TotalMysql adding vnis Mysql deleting vnisMysql totalnon-chunked sql 232245 142034 chunked in 10020 173714 1731 I've done about 5 tries to get each number to minimize random floating factor (due to swaps, disc or cpu activity or other factors) That might be surprising that issuing multiple sql statements instead one big is little bit more efficient, so I would appreciate if someone could reproduce those numbers. Also I'd like to note that part of code that iterates over vnis fetched from db is taking 10 seconds both on mysql and postgress and is a part of deleting vnis numbers. In other words, difference between multiple DELETE sql statements and single one is even bigger (in percent) than these numbers show. The code which I used to test is here: http://paste.openstack.org/show/83298/ Right now the chunked version is commented out, so to switch between versions some lines should be commented and some - uncommented. I've taken a look at this, though I'm not at the point where I have things set up to run things like this within full context, and I don't know that I have any definitive statements to make, but I do have some suggestions: 1. I do tend to chunk things a lot, selects, deletes, inserts, though the chunk size I work with is typically more like 1000, rather than 100. When chunking, we're looking to select a size that doesn't tend to overload the things that are receiving the data (query buffers, structures internal to both SQLAlchemy as well as the DBAPI and the relational database), but at the same time doesn't lead to too much repetition on the Python side (where of course there's a lot of slowness). 2. Specifically regarding WHERE x IN (.), I always chunk those. When we use IN with a list of values, we're building an actual SQL string that becomes enormous. This puts strain on the database's query engine that is not optimized for SQL strings that are hundreds of thousands of characters long, and on some backends this size is limited; on Oracle, there's a limit of 1000 items. So I'd always chunk this kind of thing. 3. I'm not sure of the broader context of this code, but in fact placing a literal list of items in the IN in this case seems unnecessary; the vmis_to_remove list itself was just SELECTed two lines above. There's
Re: [openstack-dev] [Neutron][dhcp] Agent manager customization
Hi everyone, Draft neutron spec has been defined to cover such case: https://review.openstack.org/99356 Thanks for your feedbacks, Cedric (zzelle at irc http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev) On Thu, Jun 5, 2014 at 7:27 PM, ZZelle zze...@gmail.com wrote: Hi everyone, I would like to propose a change to allow/simplify dhcp agent manager customization (like the l3-agent-consolidation spec) and i would like the community feedback. Just to precise my context, I deploy OpenStack for small specific business use cases and i often customize it because of specific use case needs. In particular sometimes i must customize dhcp agent behavior in order to: - add custom iptables rules in the dhcp namespace (on dhcp post-deployment), - remove custom iptables rules in the dhcp namespace (on dhcp pre-undeployment), - start an application like the metadata-proxy in the dhcp namespace for isolated networks (on dhcp post-deployment/update), - stop an application in the dhcp namespace for isolated networks (on dhcp pre-undeployment/update), - etc ... Currently (Havana,Icehouse), i create my own DHCP agent manager which extends neutron one and allows to define pre/post dhcp (un)deployment And I replace neutron-dhcp-agent binary, indeed it's not possible to change/hook dhcp agent manager implementation by configuration. What would be the correct way to allow dhcp agent manager customization ? For my need, allowing to: - specify dhcp agent manager implementation through configuration and - add 4 methods (pre/post dhcp (un)deployment)in dhcp manager workflow with empty implementation that can replaced using subclass would be enough. Based on other needs, a mechanism principle could be better or a monkey_patch approach (as in nova) could be more generic. I have the feeling that the correct way mustly depends on how such feature could interest the community. Thanks for your feedbacks, Cedric (zzelle at irc 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] New Contributor Agreement is not working?
Hello, I confirm ... one of my college has the same trouble. On Tue, Jun 17, 2014 at 9:57 AM, Sami J. Mäkinen sjm+osde...@hard.ware.fi wrote: Hello all. I am trying to sign the New Contributor Agreement to be able to submit a new blueprint for review. For several weeks now, I just always get an error message included below. I even suspected browser compatibility problems, but trying with Google Chrome, Opera or Firefox dit not help at all. *** Code Review - Error Server Error Cannot store contact information (button) Continue *** Pls halp! BR, -sjm ___ 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] [neutron] Firewall is ineffective with floating ip?
Hi, When the router receives packets from the external network, iptables does sequentially: 1) NAT PREROUTING table: translate floatingip to fixed ip 2) FILTER FORWARD table: apply FW rules ... on fixed ips because floatingip has been translated to fixed ip So disabling the ping to the floatingip has no effect, you should instead disable ping to associated fixed ip. More generally in (iptables) FW rules, you should use fixed-ips/cidrs as source/target not floatingips Cheers, Cedric On Thu, Jun 5, 2014 at 1:15 PM, Xurong Yang ido...@gmail.com wrote: Hi, Stackers, Use case description: Firewal is not working when setting the destination-ip-address as VM's floating ip Steps to Reproduce: 1. create one network and attached it to the newly created router 2. Create VMs on the above network 3. create security group rule for icmp 4. create an external network and attach it to the router as gateway 5. create floating ip and associate it to the VMs 6. create a first firewall rule as protocol=icmp , action =deny and desitination-ip-address as floatingip 7. create second firewall rule as protocol=any action=allow 8. attach the rule to the policy and the policy to the firewall 9. ping the VMs floating ip from network node which is having the external network configured. Actual Results: Ping succeeds Expected Results: Ping should fail as per the firewall rule router's functionality both NAT and Firewall, so , although we have created firewall rule, DNAT will take action(change floating ip to fix ip) in PREROUTING chain preferentially when network node ping vm's floating ip, so firewall rules in FORWARD chain couldn't match because packet's ip has been changed to fix ip. additional case: if we change firewall rule protocol=icmp , action =deny and desitination-ip-address as fix ip, ping fail. in short , router firewall can't take effect about floating ip. what do you think? Cheers, Xurong Yang ___ 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] [Neutron][dhcp] Agent manager customization
Hi everyone, I would like to propose a change to allow/simplify dhcp agent manager customization (like the l3-agent-consolidation spec) and i would like the community feedback. Just to precise my context, I deploy OpenStack for small specific business use cases and i often customize it because of specific use case needs. In particular sometimes i must customize dhcp agent behavior in order to: - add custom iptables rules in the dhcp namespace (on dhcp post-deployment), - remove custom iptables rules in the dhcp namespace (on dhcp pre-undeployment), - start an application like the metadata-proxy in the dhcp namespace for isolated networks (on dhcp post-deployment/update), - stop an application in the dhcp namespace for isolated networks (on dhcp pre-undeployment/update), - etc ... Currently (Havana,Icehouse), i create my own DHCP agent manager which extends neutron one and allows to define pre/post dhcp (un)deployment And I replace neutron-dhcp-agent binary, indeed it's not possible to change/hook dhcp agent manager implementation by configuration. What would be the correct way to allow dhcp agent manager customization ? For my need, allowing to: - specify dhcp agent manager implementation through configuration and - add 4 methods (pre/post dhcp (un)deployment)in dhcp manager workflow with empty implementation that can replaced using subclass would be enough. Based on other needs, a mechanism principle could be better or a monkey_patch approach (as in nova) could be more generic. I have the feeling that the correct way mustly depends on how such feature could interest the community. Thanks for your feedbacks, Cedric (zzelle at irc 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] [Neutron] One performance issue about VXLAN pool initiation
Hi, vxlan network are inserted/verified in DB one by one, which could explain the time required https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/type_vxlan.py#L138-L172 Cédric On Thu, May 29, 2014 at 12:01 PM, Xurong Yang ido...@gmail.com wrote: Hi, Folks, When we configure VXLAN range [1,16M], neutron-server service costs long time and cpu rate is very high(100%) when initiation. One test base on postgresql has been verified: more than 1h when VXLAN range is [1, 1M]. So, any good solution about this performance issue? Thanks, Xurong Yang ___ 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] [Neutron]net-create fail without definite segmentation_id
Hi, The blueprint let admins provide some provider attributes and let neutron the remaining attributes. The blueprint specification and associated implementation are under reviews[1]. [1] https://review.openstack.org/#/q/topic:bp/provider-network-partial-specs,n,z On Thu, May 29, 2014 at 1:23 PM, Henry Gessau ges...@cisco.com wrote: On 5/29/2014 4:41 AM, Xurong Yang wrote: Hi, stackers if i define provider when creating network, but no segmentation_id, net-create fail. why not allocate segmentation_id automatically? ~$ neutron net-create test --provider:network_type=vlan --provider:physical_network=default Invalid input for operation: segmentation_id required for VLAN provider network. There is a blueprint[1] to address this, with a spec[2] and some code proposed that you can find by searching for topic:bp/provider-network-partial-specs. Only for the ML2 plugin. [1] https://blueprints.launchpad.net/neutron/+spec/provider-network-partial-specs [2] https://review.openstack.org/91540 ___ 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] [All] Disabling Pushes of new Gerrit Draft Patchsets
Hello, One small remark: Work in Progress can be set only by change owners (defined in All-Projects ACLs) which could be a limitation when multiple people contribute to the same change. Cedric ZZelle@IRC On Thu, May 22, 2014 at 1:43 PM, Sergey Lukjanov slukja...@mirantis.comwrote: Great, I think it'll make CRs more consistent, especially from the reviewers PoV. On Thu, May 22, 2014 at 3:24 AM, Clark Boylan clark.boy...@gmail.com wrote: Hello everyone, Gerrit has long supported Draft patchsets, and the infra team has long recommended against using them as they are a source of bugs and confusion (see below for specific details if you are curious). The newer version of Gerrit that we recently upgraded to allows us to prevent people from pushing new Draft patchsets. We will take advantage of this and disable pushes of new Drafts on Friday May 30, 2014. The impact of this change should be small. You can use the Work in Progress state instead of Drafts for new patchsets. Any existing Draft patchsets will remain in a Draft state until it is published. Now for the fun details on why drafts are broken. * Drafts appear to be secure but they offer no security. This is bad for user expectations and may expose data that shouldn't be exposed. * Draft patchsets pushed after published patchsets confuse reviewers as they cannot vote with a value because the latest patchset is hidden. * Draft patchsets confuse the Gerrit event stream output making it difficult for automated tooling to do the correct thing with Drafts. * Child changes of Drafts will fail to merge without explanation. Let us know if you have any questions, Clark (on behalf of the infra team) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Mirantis Inc. ___ 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] [NFV][Neutron] Link to patch/review for allowing instances to receive vlan tagged traffic
The associated neutron specs: https://review.openstack.org/94612 On Thu, May 22, 2014 at 8:55 PM, Yi Sun beyo...@gmail.com wrote: Is this the one? https://review.openstack.org/#/c/92541/ On Thu, May 22, 2014 at 11:04 AM, Steve Gordon sgor...@redhat.com wrote: Hi Alan/Balazs, In one of the NFV BoF sessions in Atlanta one of you (I assume one of you anyway!) noted in the etherpad [1] (line 89) that Ericsson had submitted a patch to Neutron which would allow instances to use tagged vlan traffic. Do you happen to have a link handy to the review for this? Thanks in advance, Steve [1] https://etherpad.openstack.org/p/juno-nfv-bof ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Android-x86 http://www.android-x86.org ___ 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] [Neutron][L3] Agent manager customization
== like the generic hook system in nova (nova.hooks used in nova.compute.api) == or like the neutron ML2 mechanism hook system (neutron.plugins.ml2.driver_api:MechanismDriver) - Other idea ? It seems the same question could be asked for the dhcp agent ? Thanks, Cedric (zzelle@irc) ___ 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
