Re: [openstack-dev] Suspected SPAM - [vitrage] Nominating Yujun Zhang to Vitrage core
+1 > -Original Message- > From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com] > Sent: Sunday, June 25, 2017 3:18 PM > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Suspected SPAM - [openstack-dev] [vitrage] Nominating Yujun > Zhang to Vitrage core > > Hi, > > I’d like to nominate Yujun Zhang to the Vitrage core team. > > In the last year Yujun has made a significant contribution in Vitrage[1], both > by adding new features and by reviewing other people’s work. He has an > extensive knowledge of the Vitrage architecture and code, and I believe he > would make a great addition to our team. > > Best Regards, > Ifat. > > [1] > https://review.openstack.org/#/q/owner:zhang.yujunz%2540zte.com.cn+pr > ojects:openstack/vitrage+is:merged > > > __ > > OpenStack Development Mailing 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] [octavia] fail to plug vip to amphora
Hi, all, I am trying to create a load balancer in octavia. The amphora can be booted successfully, and can be reached via icmp. However, octavia fails to plug vip to the amphora through the amphora client api and returns 500 status code, causing some errors as follows. |__Flow 'octavia-create-loadbalancer-flow': InternalServerError: Internal Server Error 2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker Traceback (most recent call last): 2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker File "/usr/local/lib/python2.7/dist-packages/taskflow/engines/action_engine/executor.py", line 53, in _execute_task 2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker result = task.execute(**arguments) 2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker File "/opt/stack/octavia/octavia/controller/worker/tasks/amphora_driver_tasks.py", line 240, in execute 2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker amphorae_network_config) 2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker File "/opt/stack/octavia/octavia/controller/worker/tasks/amphora_driver_tasks.py", line 219, in execute 2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker amphora, loadbalancer, amphorae_network_config) 2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker File "/opt/stack/octavia/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 137, in post_vip_plug 2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker net_info) 2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker File "/opt/stack/octavia/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 378, in plug_vip 2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker return exc.check_exception(r) 2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker File "/opt/stack/octavia/octavia/amphorae/drivers/haproxy/exceptions.py", line 32, in check_exception 2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker raise responses[status_code]() 2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker InternalServerError: Internal Server Error 2017-06-21 09:49:35.864 25411 ERROR octavia.controller.worker.controller_worker To fix the problem, I log in the amphora and find that there is one http server process is listening on port 9443, so I think the amphora api services is active. But do not know how to further investigate what error happens inside the amphora api service and solve it? Look forward to your valuable comments. Best regards, Yipei __ OpenStack Development Mailing 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] For some advices about ideal contribution composition of files for OpenStack
Hi, My name is Xin Tan, majored in Computer Science, Peking University, China. I am a first year PHD student. Recently I??m doing a research on OpenStack about the contribution composition of a code file, which in order to explore the contribution pattern of different kinds of files. Further, I want to locate the risk file to give developers some useful information. I wonder if I could show you my study, including some metrics to describe the contribution composition of a code file. I would appreciate it if you could show your opinions or give some advices, which would really, really help me a lot. And it would only take you a little time. Thank you so much for your kindness. First of all, I would give you a brief introduction to my study. We all know large software projects are usually composed of some general file types. For different file types, the contribution composition of them are various. For example, the files which are responsible for implementing core functionalities are usually very complex and they are modified very often, of course, the number of contributors are very high. However, relatively independent files are usually maintained by a small number of people who have high ownership of the code. Previous studies have shown that code ownership is closely related to software quality. And it??s very easy to understand if a developer often contributes to a certain code file, he is most likely to be an expert to it. To some extent, he is the person in charge of the code file, which is conducive to the stability of the quality of the code file. But if he leaves suddenly, the risk of this code file may be very high. Therefore, starting from code ownership, we analysis the contribution composition of different file types, which in order to: 1) knowing the contribution composition of files in real time. 2) exploring the contribution pattern of different kinds of files. 3) Locating the risk file. First, we define three metrics to describe the contribution composition of files. 1) Centrality: The Centrality of a file refers to the proportion of ownership for the contributor with the highest proportion of ownership, which is calculated by the number of commit times. It could indicate that whether there is one developer who ??owns?? the file and has a high level of expertise, who can act as a single point of contact for others who need to use the component, need changes to it, or just have questions about it. 2) Diversity: We measured the uncertainty in a code file's contributions (or the diversity of sources of contributions) in a given period using the Teachman/Shannon entropy index, a commonly used diversity measure in many scientific disciplines. H(x)=E[I(xi)]=E[log(2,1/p(xi))]=-??p(xi)log(2,p(xi))(i=1,2,..n), p(xi) is the code ownership of developer xi, I(xi) means the information we need to judge if a contribution belongs to developer xi. H(x) ranges between 0, when all the contribution of the file belong to one developer in a release, and log(2, N), when N developers contribute equally (i.e., pi = 1/N) to the file. The larger H(x) is, the more diverse the contribution of the file is. We assume that the more diverse the contribution, the more bugs the code file would have in this release. And We have proven that there is a significant positive correlation between the contribution diversity and the amount of defect of the file. 3) Stability: The Stability of file means its personnel scheduling. It calculated by the total number of the contributors of this file who leave or join relative to the previous cycle. When the number of contributors to a file is instable, it usually means the high risk. Then, we choose a nova release for a case study. We define several different files types according to the functionalities of code file and refer to the measurement value. File type Example in nova The test file for active file nova/tests/unit/virt/libvirt/test_driver.py Exception handling file nova/exception.py Privilege management file etc/nova/policy.json Core interface file nova/compute/api.py Key function implementation file nova/compute/manager.py Module function implementation file nova/conductor/manager.py Function realization file of complex module nova/db/sqlalchemy/models.py Module interface file nova/api/metadata/base.py Module test file nova/tests/unit/conductor/test_conductor.py Module configuration file nova/conf/scheduler.py Non function implementation file requirements.txt i18n file nova/locale/zh_CN/LC_MESSAGES/nova.po And we calculate the above metrics of the nova active files (of course it is not accurate, because the contribution composition is effected by many factors not only file types.). We find three patterns. Centrality: low Diversity: high Stability: low Metric_1<=0.2 3=__
[openstack-dev] [Mogan]Tasks update of Mogan Project
Hi, We are glad to present this week's tasks update of Mogan. Essential Priorities 1. New flavors (zhenguo, liusheng) -- blueprint: https://blueprints.launchpad.net/mogan/+spec/new-flavor spec: https://review.openstack.org/#/c/454113/ code: Adds `disabled` field for flavors https://review.openstack.org/#/c/474441/ merged Adds `resources` field for flavors https://review.openstack.org/#/c/475626/ 2.Track resources using placement service (liusheng, zhenguo) blueprint: https://blueprints.launchpad.net/mogan/+spec/track-resources-using-placement spec: https://review.openstack.org/#/c/475700/ 3.Node aggregates (liudong, zhangyang, zhenguo) --- blueprint: https://blueprints.launchpad.net/mogan/+spec/node-aggregate spec: https://review.openstack.org/#/c/470927/ code: expose admin node list API https://review.openstack.org/#/c/470183/ merged 4.Server groups and scheduler hints(liudong, liusheng) - blueprint: https://blueprints.launchpad.net/mogan/+spec/server-group-api-extension https://blueprints.launchpad.net/mogan/+spec/support-schedule-hints spec: code: scheduler hints: https://review.openstack.org/#/c/463534/ 5. Adopt servers (wanghao, litao) blueprint: https://blueprints.launchpad.net/mogan/+spec/manage-existing-bms spec: https://review.openstack.org/#/c/459967/ under review Change the spec according to the review comments, need more review 6. Valence integration (zhenguo, shaohe, luyao, Xinran) -- blueprint: https://blueprints.launchpad.net/mogan/+spec/valence-integration spec: https://review.openstack.org/#/c/441790/3/specs/pike/approved/valence-integration.rst code: No updates 7. Specify neutron port when creating servers(wanghao) -- blurprint: https://blueprints.launchpad.net/mogan/+spec/specify-neutron-port-when-creating-instances code: https://review.openstack.org/#/c/470824/ merged __ OpenStack Development Mailing 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] [vitrage] Nominating Yujun Zhang to Vitrage core
+1 On Jun 25, 2017 15:20, "Afek, Ifat (Nokia - IL/Kfar Sava)" < ifat.a...@nokia.com> wrote: > Hi, > > I’d like to nominate Yujun Zhang to the Vitrage core team. > > In the last year Yujun has made a significant contribution in Vitrage[1], > both by adding new features and by reviewing other people’s work. He has an > extensive knowledge of the Vitrage architecture and code, and I believe he > would make a great addition to our team. > > Best Regards, > Ifat. > > [1] https://review.openstack.org/#/q/owner:zhang.yujunz%2540zte. > com.cn+projects:openstack/vitrage+is:merged > > > __ > OpenStack Development Mailing 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] [vitrage] Nominating Yujun Zhang to Vitrage core
Hi, I’d like to nominate Yujun Zhang to the Vitrage core team. In the last year Yujun has made a significant contribution in Vitrage[1], both by adding new features and by reviewing other people’s work. He has an extensive knowledge of the Vitrage architecture and code, and I believe he would make a great addition to our team. Best Regards, Ifat. [1] https://review.openstack.org/#/q/owner:zhang.yujunz%2540zte.com.cn+projects:openstack/vitrage+is:merged __ OpenStack Development Mailing 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] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC
Hi All, I am interested to know if there are any meters available for monitoring SFC through ceilometer, like no.of flows associated with an SFC or packets in/out for an SFC etc? If they are available, please let me know how to configure and use them. If not, are there any plans of providing support to them in coming releases? Thanking you, Regards, Rajeev. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO][CI][containers] Broken container gate jobs block patches.
Hi, FYI that gates now are blocked because of [1] and containers jobs now are part of gate jobs. Please try to resolve it asap. Thanks [1] CI: containers jobs fail in pingtest because volume error: https://bugs.launchpad.net/tripleo/+bug/1700333 -- Best regards Sagi Shnaidman __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] realtime kvm cpu affinities
On Fri, Jun 23, 2017 at 10:34:26AM -0600, Chris Friesen wrote: > On 06/23/2017 09:35 AM, Henning Schild wrote: > > Am Fri, 23 Jun 2017 11:11:10 +0200 > > schrieb Sahid Orentino Ferdjaoui : > > > > In Linux RT context, and as you mentioned, the non-RT vCPU can acquire > > > some guest kernel lock, then be pre-empted by emulator thread while > > > holding this lock. This situation blocks RT vCPUs from doing its > > > work. So that is why we have implemented [2]. For DPDK I don't think > > > we have such problems because it's running in userland. > > > > > > So for DPDK context I think we could have a mask like we have for RT > > > and basically considering vCPU0 to handle best effort works (emulator > > > threads, SSH...). I think it's the current pattern used by DPDK users. > > > > DPDK is just a library and one can imagine an application that has > > cross-core communication/synchronisation needs where the emulator > > slowing down vpu0 will also slow down vcpu1. You DPDK application would > > have to know which of its cores did not get a full pcpu. > > > > I am not sure what the DPDK-example is doing in this discussion, would > > that not just be cpu_policy=dedicated? I guess normal behaviour of > > dedicated is that emulators and io happily share pCPUs with vCPUs and > > you are looking for a way to restrict emulators/io to a subset of pCPUs > > because you can live with some of them beeing not 100%. > > Yes. A typical DPDK-using VM might look something like this: > > vCPU0: non-realtime, housekeeping and I/O, handles all virtual interrupts > and "normal" linux stuff, emulator runs on same pCPU > vCPU1: realtime, runs in tight loop in userspace processing packets > vCPU2: realtime, runs in tight loop in userspace processing packets > vCPU3: realtime, runs in tight loop in userspace processing packets > > In this context, vCPUs 1-3 don't really ever enter the kernel, and we've > offloaded as much kernel work as possible from them onto vCPU0. This works > pretty well with the current system. > > > > For RT we have to isolate the emulator threads to an additional pCPU > > > per guests or as your are suggesting to a set of pCPUs for all the > > > guests running. > > > > > > I think we should introduce a new option: > > > > > >- hw:cpu_emulator_threads_mask=^1 > > > > > > If on 'nova.conf' - that mask will be applied to the set of all host > > > CPUs (vcpu_pin_set) to basically pack the emulator threads of all VMs > > > running here (useful for RT context). > > > > That would allow modelling exactly what we need. > > In nova.conf we are talking absolute known values, no need for a mask > > and a set is much easier to read. Also using the same name does not > > sound like a good idea. > > And the name vcpu_pin_set clearly suggest what kind of load runs here, > > if using a mask it should be called pin_set. > > I agree with Henning. > > In nova.conf we should just use a set, something like > "rt_emulator_vcpu_pin_set" which would be used for running the emulator/io > threads of *only* realtime instances. I'm not agree with you, we have a set of pCPUs and we want to substract some of them for the emulator threads. We need a mask. The only set we need is to selection which pCPUs Nova can use (vcpus_pin_set). > We may also want to have "rt_emulator_overcommit_ratio" to control how many > threads/instances we allow per pCPU. Not really sure to have understand this point? If it is to indicate that for a pCPU isolated we want X guest emulator threads, the same behavior is achieved by the mask. A host for realtime is dedicated for realtime, no overcommitment and the operators know the number of host CPUs, they can easily deduct a ratio and so the corresponding mask. > > > If on flavor extra-specs It will be applied to the vCPUs dedicated for > > > the guest (useful for DPDK context). > > > > And if both are present the flavor wins and nova.conf is ignored? > > In the flavor I'd like to see it be a full bitmask, not an exclusion mask > with an implicit full set. Thus the end-user could specify > "hw:cpu_emulator_threads_mask=0" and get the emulator threads to run > alongside vCPU0. Same here, I'm not agree, the only set is the vCPUs of the guest. Then we want a mask to substract some of them. > Henning, there is no conflict, the nova.conf setting and the flavor setting > are used for two different things. > > Chris > > __ > OpenStack Development Mailing 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
