[openstack-dev] [mistral] Team meeting - 07/13/2015
Hi, This is a reminder that we’ll have a team meeting today at #openstack-mistral at 16.00 UTC. Agenda: Review action items Current status (progress, issues, roadblocks, further plans) Dashboard progress Liberty-2 progress Open discussion Add your topics either by replying to this email or modifying https://wiki.openstack.org/wiki/Meetings/MistralAgenda https://wiki.openstack.org/wiki/Meetings/MistralAgenda. Renat Akhmerov @ Mirantis Inc. __ 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] [murano] [congress] Congress needs to fetch environments from all tenants.
Hi Dolph Thanks for idea. Is this approach used somewhere for similar use-case I described? If so please point it out. Thanks Filip On 07/10/2015 04:57 PM, Dolph Mathews wrote: How about using domain-based role assignments in keystone and requiring domain-level authorization in policy, and then only returning data about the collection of tenants that belong to the authorized domain? That way you don't have an API that violates multi-tenant isolation, consumable only by cloud operators. On Wed, Jul 8, 2015 at 6:27 AM, Filip Blaha filip.bl...@hp.com mailto:filip.bl...@hp.com wrote: Hi all, I started implement bp [1]. Problem is that congress needs data about environments from all tenants but murano API lists only environments of user's current tenant. We decided to ipmplement it similarly like listing servers in nova where is query parameter all_tenants=true for that (user must be admin) I have 2 questions about that: 1) Are there any security concerns about this approach? 2) Has someone better idea how to implement this? [1] https://blueprints.launchpad.net/murano/+spec/murano-api-all-tenants-search Regards Filip __ 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 __ 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] [CI] How to set a proxy for zuul.
Updating jobs using sudo jenkins-jobs --flush-cache update /etc/jenkins_jobs/config/. Also update the myvendor in examples.yaml On Mon, Jul 13, 2015 at 1:45 PM, Tang Chen tangc...@cn.fujitsu.com wrote: On 07/13/2015 03:50 PM, Abhishek Shrivastava wrote: Use tester or something, also are you updating the jobs or not? I used tester as my vendor. It doesn't work. And what do you mean by updating the jobs ? I built the noop-check-cimmunitication job once in Jenkins UI. Does it matter ? All the others are not touched. And referring to the error, Project openstack-dev/sandbox not found, it seems like somewhere the project name was wrong. right ? Thanks. On Mon, Jul 13, 2015 at 1:16 PM, Tang Chen tangc...@cn.fujitsu.com wrote: Hi Abhishek, Thanks for the quick reply. On 07/13/2015 03:16 PM, Abhishek Shrivastava wrote: Also check that Gearman is connecting or not through Jenkins UI. On Mon, Jul 13, 2015 at 12:45 PM, Abhishek Shrivastava abhis...@cloudbyte.com wrote: First of all, change the vendor to your vendor name in /etc/jenkins_jobs/config/projects.yaml file. Also, restart the zuul and zuul merger. I did the check. Gearman plugin works find. In Jenkins UI, I tested the connection, and it succeeded. And also, I restarted zuul and zuul merger every time I modified the yaml files. But it doesn't work. And the vendor, does that matter ? And what vendor name should I provide ? I cannot find any vendor info in my Gerrit service account profile. For example, is XXX OK ? Thanks. On Mon, Jul 13, 2015 at 12:29 PM, Tang Chen tangc...@cn.fujitsu.com wrote: Hi all, I have constructed my CI system. When I tested it with sandbox project, I posted a patch to Gerrit. https://review.openstack.org/201002 But I got this error in zuul scheduler: 2015-07-14 14:07:24,921 DEBUG zuul.Scheduler: Run handler awake 2015-07-14 14:07:24,921 DEBUG zuul.Scheduler: Fetching trigger event 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Processing trigger event TriggerEvent comment-added openstack-dev/sandbox master 201002,1 Verified:1 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Project openstack-dev/sandbox not found 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Run handler sleeping My /etc/zuul/layout/layout.yaml looks like this: projects: - name: openstack-dev/sandbox check: - noop-check-communication My /etc/jenkins_jobs/config/projects.yaml looks like this: - project: name: sandbox github-org: openstack-dev node: master vendor: myvendor jobs: - noop-check-communication - dsvm-tempest-full: node: 'devstack_slave || devstack-precise-check || d-p-c' And Jenkins master works fine. Does anyone know what is going on here ? Thanks. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Thanks Regards, * *Abhishek* *Cloudbyte Inc. http://www.cloudbyte.com* -- *Thanks Regards, * *Abhishek* *Cloudbyte Inc. http://www.cloudbyte.com* __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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 -- *Thanks Regards, * *Abhishek* *Cloudbyte Inc. http://www.cloudbyte.com* __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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 -- *Thanks Regards,* *Abhishek* *Cloudbyte Inc. http://www.cloudbyte.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] FWaaS and the conntrack table
Hi, I've faced a problem with FWaaS plugin in Neutron (Juno). The firewall works, but when I delete a rule from the policy, the connection will still works because of conntrack... (I tried with ping, and ssh) It's okay, if the connection will kept alive, if it's really alive, (an active SSH for example) but if I delete the ICMP rule, and stop pinging, and restart pinging, the ping will still works... If I go to my neutron server, and do a conntrack -F command on my relevant qrouter, the firewall starts working based on the valid rules... Are there any way, to configure the conntrack cleanup when FWaaS configuration modified by user? If not, can somebody help me, where to make changes on code, to run that command in the proper namespace after the iptables rule-generation? Regards, Peter ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [neutron][qos] Priorities Status for QoS
Miguel Angel Ajo wrote: I've been working on assembling a QoS[1] POC since last day of the coding sprint in Israel [2], Ihar has reported to the list our plan to get into master [3]. I've been able to validate and integrate lots of the patches, and find the gaps, while still finishing the top-down assembly may require a few more hours, or an extra day, I believe we should prioritize the work to make such POC available for easy consumption in feature/qos. For that to happen, we should prioritize review and merge of the following patches into the branch: (I'd be very thankful to any review cycles anyone could spend on this, specially cores, of course) QoS service plugin: * https://review.openstack.org/#/c/197564/ * https://review.openstack.org/#/c/197898/ Agent side: * https://review.openstack.org/#/c/195440/ (I just found a bug in the logic, working to submit a new PS) * https://review.openstack.org/#/c/197557/ (waiting for merge, dependent on other patch) DB Models Versioned Objects (unit tests+ fixes): * https://review.openstack.org/#/c/25/ * https://review.openstack.org/#/c/200036/ * https://review.openstack.org/#/c/200418/ -- ready for merge, waiting on rebase from master, failing on the mock-hell: * https://review.openstack.org/#/c/198163/ * https://review.openstack.org/#/c/197898/ * https://review.openstack.org/#/c/199627/ * https://review.openstack.org/#/c/199634/ Extra stones: a) @armax, please check where I make sense here, I believe I do, but of course I want your opinion: We also need to introduce new BEFORE_UPDATE callbacks for ports and networks before any call to plugin. So we'll be able to retrieve qos_profile_id, and check it, and associate/dissociate network/port to profile. Talking to Mike Kolesnik, who is currently working into this piece, he just realized which what I'm saying here it's partly wrong. We need BEFORE_UPDATE to validate the data it's being provided (qos_policy_id permissions, existence, etc..) and otherwise throw an exception. Then we need AFTER_UPDATE (when we're sure nobody threw an exception) to really stick it to the database, and, send a message to the QoS backend to configure the ports. AFTER_UPDATE is working ok here, with a few workarounds, since, for example, it's called from ML2, and ML2, will only push information of the port when the port has changed anything relevant to ML2, and won't even provide the port_id ... I'm not sure where this is used/what's the use case. And we need to extend the understanding of ML2 changed information to detect changes to qos_profile_id and send such information down the line (agents the AFTER_UPDATE). b) rule list handling in the policy versioned object (Ihar is handling that here, WIP): https://review.openstack.org/#/c/200608/ c) serializing and deserializing the policy - rules dictionary over the wire (thanks to versioned objects). Afterwards, we must follow with the plan Ihar explained in [3], we don't have much time, so, if you have an interest on QoS, please join the effort and help us with anything you can if you want it as an experimental feature available by L. Quality Regards ;) Miguel Ángel [1] http://specs.openstack.org/openstack/neutron-specs/specs/liberty/qos-api-extension.html [2] TL;DR report, with nice pictures : http://www.ajo.es/post/123458887419/neutron-quality-of-service-coding-sprint [3] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069188.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
Rob, Please see: https://etherpad.openstack.org/p/juno-cross-project-future-of-python -- dims On Mon, Jul 13, 2015 at 5:39 AM, Robert Collins robe...@robertcollins.net wrote: On 13 July 2015 at 20:08, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/13/2015 03:29 AM, Robert Collins wrote: So, we've got constraints support for tox coming together nicely. The rollout for that will be per project (because tox.ini needs to change). However, we're not compiling, nor are we easily able to do so, a constraints set for Python 2.6. (We compile one unified file with all our constraints, which requires a VM with all the Python's we need to use installed on it). Enabling constraints on py2.6 tox jobs will fail to constrain anything which varies by Python version. So - folk that haven't disabled their 2.6 jobs (you know who you are) - you probably want to do so now in master. Its' my understanding that they were meant to be disabled during kilo but they've fallen through the cracks. clients and oslo libraries still maintain their py26 for a reason: decision to drop py26 was for server projects only. Huh. I wasn't part of that discussion... does anyone have a link to why we're supporting a release upstream have completely moved on from 2 years ago? Surely folk wanting to use clients from Python2.6 could just use our older API clients, which due to good backwards compat should still work. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[Openstack] Neutron notifiers error on instance delete
Hello, When deleting a instance by the openstack API (DELETE {tenant_id}/servers/{server_id}) we see the following error on the neutron server, the instance isn’t deleted and change to error status: 2015-07-06 13:00:31.084 45873 ERROR neutron.notifiers.nova [req-7cf6c8a7-15a2-4c7e-8a84-97e173697ab0 None] Failed to notify nova on events: [{'status': 'completed', 'tag': u'267d2fc6-8ccb-4e6a-b88b-9caa3f09ba83', 'name': 'network-vif-unplugged', 'server_uuid': u'1eb1b855-e8fd-4df0-840e-d5fae0b69dda'}] 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova Traceback (most recent call last): 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/neutron/notifiers/nova.py, line 187, in send_events 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova batched_events) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/novaclient/v1_1/contrib/server_external_events.py, line 39, in create 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova return_raw=True) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/novaclient/base.py, line 152, in _create 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova _resp, body = self.api.client.post(url, body=body) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/novaclient/client.py, line 312, in post 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova return self._cs_request(url, 'POST', **kwargs) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/novaclient/client.py, line 298, in _cs_request 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova method, **kwargs) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/novaclient/client.py, line 268, in _time_request 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova resp, body = self.request(url, method, **kwargs) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/novaclient/client.py, line 262, in request 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova raise exceptions.from_response(resp, body, url, method) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova NotFound: No instances found for any event (HTTP 404) (Request-ID: req-63a9ba3f-f1d3-4c5f-ae94-e6a7b4e6bb15) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova 2015-07-06 13:00:31.130 45873 INFO neutron.wsgi [-] (45873) accepted ('10.121.36.25', 49882) Any help appreciated! Cheers, Chris ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [puppet] running tempest on beaker jobs
On 07/12/2015 11:29 PM, Matt Fischer wrote: We used Tempest for a time against our production environment. It was a pain to clean up but ephemeral test jobs solves that for you. A few questions: What version of tempest will be using? master for now. We will see if new tags are created later. AFIK, tags mean Tempest does not support an old version of OpenStack (ie, tempest 5 only support juno / kilo / current (liberty)). Will we maintain a blacklist if there are known failures? (although this is a pain to keep updated) I don't think we'll have to, since tempest already provide some Python decorators to skip some bugs. If that happens, yes we'll have to find a way to exclude some tests or disable the run at all. That's why having it running without affecting job return code does not break anything now. On Sun, Jul 12, 2015 at 8:44 PM, Emilien Macchi emilien.mac...@gmail.com mailto:emilien.mac...@gmail.com wrote: Hi, I would like to propose to run Tempest at the end of the beaker jobs, for testing purpose now. As a start, we would accept 0 1 as return code, because this is really experimental. Though I think it will be interesting to see how it behaves, specially when we implement new configurations or plugins in our modules. I already did a PoC for puppet-keystone: https://review.openstack.org/198561 (failing because it needs more work to pass keystone v3 tests but v2 tests are successful). As you can see the code is really light, since we use puppet-tempest. Any suggestion is welcome ! -- Emilien Macchi __ 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 __ 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 -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ 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] [Fuel][Fuel-Packaging][Fuel-CI][Fuel-Infra] How to Deal with CI Failures Induced by Libraries Requirements Drift
Oleg The problem here is that you have this code released and it is running in production - how are you going to fix this? Pin requirements and deal with dependency hell? Seriously, it is much easier to deal with explicitly frozen mirror which is created by one 'pip install ' run than to play with implicit transitive dependencies. On Mon, Jul 13, 2015 at 11:58 AM, Oleg Gelbukh ogelb...@mirantis.com wrote: Some comments inline. On Mon, Jul 13, 2015 at 9:24 AM, Bartlomiej Piotrowski bpiotrow...@mirantis.com wrote: Freezing every moving part is complete overkill and puts a heavy burden on devops team as well as infra itself. The fix couldn't be more simple: just put upper bounds in requirements. 1) if there is a new conflicting version, you need to set this upper-bound, thus you need to modify bits which get released It should be done as part of hard code freeze. As I understand, in this cases it is not code dependencies that cause misfunction, but dependencies of tests. This can be fixed by pinning test-requirements. We can do this any time, as it does not affect users. 2) you are actually testing your code by linking it with libraries which are different from those that users are really using when running your code Packages dependencies should reflect these set in requirements. 3) even if you specify an upper bound (or even fix the version) for this particular library, you may still fetch its newer dependency implicitly (by traversing indirect dependencies) with which you will be linking your libraries and which will actually be different from the code that you (and your users) use This can be actually said about anything, including base system Fuel is running. We simply do not support such setups. That's why we should run CI and nightly builds on stable branches. It catches exactly this type of issues. 4) you may also break production installation if you fix some library version as it may not exist in the code bundle which gets delivered to your users as a set of package See 2. Again, if something in code deps breaks our stable branch, we must learn it as soon as possible and fix it there. However, in this case it ist the test requirements failure, and it should pinned in 'test-requirements.txt' or in requirements of our test suits. -- Best regards, Oleg Gelbukh BP __ 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 -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.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
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
On 2015-07-13 10:08:16 +0200 (+0200), Ihar Hrachyshka wrote: clients and oslo libraries still maintain their py26 for a reason: decision to drop py26 was for server projects only. Yes, that decision was made at a time when our server projects had stable branches, but our clients and shared libraries did not. My recollection is that server projects only was a proxy for only projects with stable branches. Now that we have stable branches of, say, python-novaclient where we can backport juno-relevant security fixes, people on 2.6-only platforms who want to install and run python-novaclient from PyPI can use the stable/juno version (though I'll admit that finding which version works with 2.6 may be a tricky proposition for a consumer who is unaware of this situation). -- 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
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
On 13/07/2015 13:57, Jeremy Stanley wrote: people on 2.6-only platforms who want to install and run python-novaclient from PyPI can use the stable/juno version (though I'll admit that finding which version works with 2.6 may be a tricky proposition for a consumer who is unaware of this situation). Hopefully, some Linux distro package python-novaclient and so user don't have to guess the version compatible with their OS. https://packages.debian.org/jessie/python-novaclient http://packages.ubuntu.com/fr/precise/python/python-novaclient https://admin.fedoraproject.org/pkgdb/package/python-novaclient/ https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/6/html/Command-Line_Interface_Reference_Guide/install_clients.html etc. Victor __ 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] disk I/O perfomance
Hello, Warren. Yes, we use properly filled file on a single splining drive. All tests are done with fio, here is a link on full test report - http://koder-ua.github.io/6.1GA/ephemeral_drive.html. Here is a link on report for same test, executed directly on HDD, used for ephemeral storage - http://koder-ua.github.io/6.1GA/compute_node_HDD.html. We are using QEMU Debian 2.0.0+dfsg-2ubuntu1.13. Your command has following output: virtio-blk-device.drive=drive virtio-blk-device.logical_block_size=blocksize virtio-blk-device.physical_block_size=blocksize virtio-blk-device.min_io_size=uint16 virtio-blk-device.opt_io_size=uint32 virtio-blk-device.bootindex=int32 virtio-blk-device.discard_granularity=uint32 virtio-blk-device.cyls=uint32 virtio-blk-device.heads=uint32 virtio-blk-device.secs=uint32 virtio-blk-device.serial=str virtio-blk-device.config-wce=on/off virtio-blk-device.scsi=on/off virtio-blk-device.x-iothread=iothread There only one vm on this compute node, and there a lot of free resources. Ballooning driver should not influence performance(FUEL 6.1). Kind regards, Gleb Stepanov. On Fri, Jul 10, 2015 at 11:10 PM, Konstantin Danilov kdani...@mirantis.com wrote: ...spinning drive based on fio. splining drive. All tests are done with fio, here is a link on full test report - http://koder-ua.github.io/6.1GA/ephemeral_drive.html. Here is a link on report for same test, executed directly on HDD, used for ephemeral storage - http://koder-ua.github.io/6.1GA/compute_node_HDD.html. We use following version of QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.13). We are using QEMU Debian 2.0.0+dfsg-2ubuntu1.13. We have not used enviroment fully, so i guess there is not affection of balloning. There only one vm on this compute node, and there a lot of free resources. Ballooning driver should not influence performance(FUEL 6.1). On Fri, Jul 10, 2015 at 11:00 PM, Gleb Stepanov gstepa...@mirantis.com wrote: Hello, Warren. Yes, we use properly filled file on a single spinning drive based on fio. We use following version of QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.13). Your command has following output: virtio-blk-device.drive=drive virtio-blk-device.logical_block_size=blocksize virtio-blk-device.physical_block_size=blocksize virtio-blk-device.min_io_size=uint16 virtio-blk-device.opt_io_size=uint32 virtio-blk-device.bootindex=int32 virtio-blk-device.discard_granularity=uint32 virtio-blk-device.cyls=uint32 virtio-blk-device.heads=uint32 virtio-blk-device.secs=uint32 virtio-blk-device.serial=str virtio-blk-device.config-wce=on/off virtio-blk-device.scsi=on/off virtio-blk-device.x-iothread=iothread We have not used enviroment fully, so i guess there is not affection of balloning. Kind regards, Gleb Stepanov. On Fri, Jul 10, 2015 at 6:01 PM, Gleb Stepanov gstepa...@mirantis.com wrote: -- Forwarded message -- From: Gleb Stepanov gstepa...@mirantis.com Date: Wed, Jul 8, 2015 at 1:58 PM Subject: [nova] disk I/O perfomance To: openstack-operat...@lists.openstack.org, openstack-dev@lists.openstack.org Hello, all. We have measured disk I/O performance on openstack virtual machines with aid of FIO tool. We've tested performance on root dist drive device, test consists of write operationby 4kb blocks to file with size 90Gb (prefilled in advance). We use qcow2 image for vm, ephemeral drive and virtio driver. All configuration goes in attachment. There are some results: test 1 threads 1, 5, 10, 15, 20, 40 iops 72,58,49,60,94,72 test 2 threads 1, 5, 10, 15, 20, 40 iops 71,60,54,88,52,52 test 3 threads 1, 5, 10, 15, 20, 40 iops 71,49,58,51,128,130 test 4 threads 1, 5, 10, 15, 20, 40 iops 65,49,60,56,52,63 As it is shown performance degraded during increasing amount of threads, also deviation of results on 40 threads is very big. Have you any ideas how to explain performance behaviour? Kind regards, Gleb Stepanov. -- Kostiantyn Danilov aka koder.ua Principal software engineer, Mirantis skype:koder.ua http://koder-ua.blogspot.com/ http://mirantis.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
Re: [openstack-dev] [Cinder]Restrict volume creation based on type
Hi, Thanks for your replies. Got back to the team and tried to get more input: - the volume is created correctly (i misunderstood that part) - the problem is that (sometimes) the instance gets spawned on the 3rd node (which doesn't have the driver configured). This might be because of the availability zone (volume has AZ nova, instance has AZ nova, which refers to all 3 nodes). I was not able to reproduce this on L, team tried with J, i will retry with J and K and get back to you. @Gorka: no, the hostnames are different @Duncan: the extra-specs are volume_backend_name: swift200 Thanks, Eduard __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
On 13 July 2015 at 20:08, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/13/2015 03:29 AM, Robert Collins wrote: So, we've got constraints support for tox coming together nicely. The rollout for that will be per project (because tox.ini needs to change). However, we're not compiling, nor are we easily able to do so, a constraints set for Python 2.6. (We compile one unified file with all our constraints, which requires a VM with all the Python's we need to use installed on it). Enabling constraints on py2.6 tox jobs will fail to constrain anything which varies by Python version. So - folk that haven't disabled their 2.6 jobs (you know who you are) - you probably want to do so now in master. Its' my understanding that they were meant to be disabled during kilo but they've fallen through the cracks. clients and oslo libraries still maintain their py26 for a reason: decision to drop py26 was for server projects only. Huh. I wasn't part of that discussion... does anyone have a link to why we're supporting a release upstream have completely moved on from 2 years ago? Surely folk wanting to use clients from Python2.6 could just use our older API clients, which due to good backwards compat should still work. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ 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] [CI] How to set a proxy for zuul.
On 07/13/2015 04:35 PM, Abhishek Shrivastava wrote: Updating jobs using sudo jenkins-jobs --flush-cache update /etc/jenkins_jobs/config/. Also update the myvendor in examples.yaml Sorry, I updated the jobs, restart the whole machine. But it still doesn't work. By the way, there is no vendor in examples.yaml. It is still this error: Project openstack-dev/sandbox not found Anything else should I pay attention to? Thanks. On Mon, Jul 13, 2015 at 1:45 PM, Tang Chen tangc...@cn.fujitsu.com mailto:tangc...@cn.fujitsu.com wrote: On 07/13/2015 03:50 PM, Abhishek Shrivastava wrote: Use tester or something, also are you updating the jobs or not? I used tester as my vendor. It doesn't work. And what do you mean by updating the jobs ? I built the noop-check-cimmunitication job once in Jenkins UI. Does it matter ? All the others are not touched. And referring to the error, Project openstack-dev/sandbox not found, it seems like somewhere the project name was wrong. right ? Thanks. On Mon, Jul 13, 2015 at 1:16 PM, Tang Chen tangc...@cn.fujitsu.com mailto:tangc...@cn.fujitsu.com wrote: Hi Abhishek, Thanks for the quick reply. On 07/13/2015 03:16 PM, Abhishek Shrivastava wrote: Also check that Gearman is connecting or not through Jenkins UI. On Mon, Jul 13, 2015 at 12:45 PM, Abhishek Shrivastava abhis...@cloudbyte.com mailto:abhis...@cloudbyte.com wrote: First of all, change the vendor to your vendor name in /etc/jenkins_jobs/config/projects.yaml file. Also, restart the zuul and zuul merger. I did the check. Gearman plugin works find. In Jenkins UI, I tested the connection, and it succeeded. And also, I restarted zuul and zuul merger every time I modified the yaml files. But it doesn't work. And the vendor, does that matter ? And what vendor name should I provide ? I cannot find any vendor info in my Gerrit service account profile. For example, is XXX OK ? Thanks. On Mon, Jul 13, 2015 at 12:29 PM, Tang Chen tangc...@cn.fujitsu.com mailto:tangc...@cn.fujitsu.com wrote: Hi all, I have constructed my CI system. When I tested it with sandbox project, I posted a patch to Gerrit. https://review.openstack.org/201002 But I got this error in zuul scheduler: 2015-07-14 14:07:24,921 DEBUG zuul.Scheduler: Run handler awake 2015-07-14 14:07:24,921 DEBUG zuul.Scheduler: Fetching trigger event 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Processing trigger event TriggerEvent comment-added openstack-dev/sandbox master 201002,1 Verified:1 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Project openstack-dev/sandbox not found 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Run handler sleeping My /etc/zuul/layout/layout.yaml looks like this: projects: - name: openstack-dev/sandbox check: - noop-check-communication My /etc/jenkins_jobs/config/projects.yaml looks like this: - project: name: sandbox github-org: openstack-dev node: master vendor: myvendor jobs: - noop-check-communication - dsvm-tempest-full: node: 'devstack_slave || devstack-precise-check || d-p-c' And Jenkins master works fine. Does anyone know what is going on here ? Thanks. __ 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 -- * * *Thanks Regards, * *Abhishek* /_Cloudbyte Inc. http://www.cloudbyte.com_/ -- * * *Thanks Regards, * *Abhishek* /_Cloudbyte Inc. http://www.cloudbyte.com_/ __ OpenStack Development Mailing List (not for usage questions)
Re: [openstack-dev] [openstack][cinder]A discussion about quota update lower than current usage.
The problem is, if you reject the request to lower quota unless the usage is under the new quota, you've got an inherently racy process where the admin needs to communicate with the tenant to say 'Stop using some of your quota while I reduce it', which is no less complicated than 'I've reduced your quota, now delete some resources to get under it'. It honestly sounds like the right thing to do here is to educate the admins who are surprised by the current behaviour, rather than to introduce a new behaviour that is fundamentally no better. On 13 July 2015 at 12:14, hao wang sxmatch1...@gmail.com wrote: Hi, Mike I'm not sure we really don't need any change about this feature. At least, some end users I faced to think there should be changed IMHO, there is a main problem that some users whom I faced to can't understand: What's the purpose that admin reduce quota lowner than existing usage? Limit user to can't create any resources any more? But why reduce quota just equal the current usage, it has same function. Make user to delete their resources lower than the new limit line? It's weak if user don't want to do that deletion and also bring some confusion to other users that I have mentioned. I understood there may be 100 reasons to show me why admin can reduce the quota lower than usage, and I don't want to object them too. But I hope this change can bring some new usage to update quota: 1. When admin use client(could be third party) to update the quota limit, they should check quota usage first as winston mentioned, if they don't or forget, anyway, they will change failed if quota is lower than usage, since we give the ability to cinder it will stop them to do that thing and make admin back to check quota usage. 2. If admin know what they are doing and just need to reduce the limit lower for some reason, fine, take the option argument '--force' or '--skip_validation' to update the quota. In personally, I felt this routine may be more improvement and little confusion with it. I knew Eric said that of course we can implement this purpose by using current APIs, it's a alternatives, but it depends on the application which is top on cinder I think, and is hard to have consistent. 2015-07-11 7:24 GMT+08:00 Mike Perez thin...@gmail.com: On 12:30 Jul 10, hao wang wrote: Cinder now doesn't check the existing resource when user lower the quota. It's reasonable for admin can adjust the quota limit to lower level than current usage. But it also bring confusion that I have received to end user, they saw the current usage was more than limit, but they can't create resources any more. So there have been 'bug' reported[1] and code patch[2] committed, I knew it may be inappropriate as 'bug fix', but just want to optimize this API of updating quota. We are proposing to add an option argument which is named 'force' in request body. Of course the default value is True that means admin can adjust the quota lower then current usage as same as what we did now. When the force is False, that will occur a Validation and return 400 Bad Request if the update value is lower than current usage. I wonder to know folks' opinions and suggestions about this change to see if this is value to merge this patch. Based on the feedback received in the bug and review, it seems like there is a clear consensus that people don't want this, even if it can be bypassed with a force option. -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best Wishes For You! __ 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 -- -- Duncan Thomas __ 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] Time to remove Python2.6 jobs from master
On 2015-07-13 06:03:56 -0400 (-0400), Davanum Srinivas wrote: Please see: https://etherpad.openstack.org/p/juno-cross-project-future-of-python That decision happened at a time when there were no stable branches of clients/libs and no expectation of their existence. Since then the situation has changed, and it's worth revisiting that choice. -- 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
Re: [openstack-dev] [openstack][cinder]A discussion about quota update lower than current usage.
Hi, Mike I'm not sure we really don't need any change about this feature. At least, some end users I faced to think there should be changed IMHO, there is a main problem that some users whom I faced to can't understand: What's the purpose that admin reduce quota lowner than existing usage? Limit user to can't create any resources any more? But why reduce quota just equal the current usage, it has same function. Make user to delete their resources lower than the new limit line? It's weak if user don't want to do that deletion and also bring some confusion to other users that I have mentioned. I understood there may be 100 reasons to show me why admin can reduce the quota lower than usage, and I don't want to object them too. But I hope this change can bring some new usage to update quota: 1. When admin use client(could be third party) to update the quota limit, they should check quota usage first as winston mentioned, if they don't or forget, anyway, they will change failed if quota is lower than usage, since we give the ability to cinder it will stop them to do that thing and make admin back to check quota usage. 2. If admin know what they are doing and just need to reduce the limit lower for some reason, fine, take the option argument '--force' or '--skip_validation' to update the quota. In personally, I felt this routine may be more improvement and little confusion with it. I knew Eric said that of course we can implement this purpose by using current APIs, it's a alternatives, but it depends on the application which is top on cinder I think, and is hard to have consistent. 2015-07-11 7:24 GMT+08:00 Mike Perez thin...@gmail.com: On 12:30 Jul 10, hao wang wrote: Cinder now doesn't check the existing resource when user lower the quota. It's reasonable for admin can adjust the quota limit to lower level than current usage. But it also bring confusion that I have received to end user, they saw the current usage was more than limit, but they can't create resources any more. So there have been 'bug' reported[1] and code patch[2] committed, I knew it may be inappropriate as 'bug fix', but just want to optimize this API of updating quota. We are proposing to add an option argument which is named 'force' in request body. Of course the default value is True that means admin can adjust the quota lower then current usage as same as what we did now. When the force is False, that will occur a Validation and return 400 Bad Request if the update value is lower than current usage. I wonder to know folks' opinions and suggestions about this change to see if this is value to merge this patch. Based on the feedback received in the bug and review, it seems like there is a clear consensus that people don't want this, even if it can be bypassed with a force option. -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best Wishes For You! __ 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-operators] [nova] disk I/O perfomance
Hello, Warren. Yes, we use properly filled file on a single splining drive. All tests are done with fio, here is a link on full test report - http://koder-ua.github.io/6.1GA/ephemeral_drive.html. Here is a link on report for same test, executed directly on HDD, used for ephemeral storage - http://koder-ua.github.io/6.1GA/compute_node_HDD.html. We are using QEMU Debian 2.0.0+dfsg-2ubuntu1.13. Your command has following output: virtio-blk-device.drive=drive virtio-blk-device.logical_block_size=blocksize virtio-blk-device.physical_block_size=blocksize virtio-blk-device.min_io_size=uint16 virtio-blk-device.opt_io_size=uint32 virtio-blk-device.bootindex=int32 virtio-blk-device.discard_granularity=uint32 virtio-blk-device.cyls=uint32 virtio-blk-device.heads=uint32 virtio-blk-device.secs=uint32 virtio-blk-device.serial=str virtio-blk-device.config-wce=on/off virtio-blk-device.scsi=on/off virtio-blk-device.x-iothread=iothread There only one vm on this compute node, and there a lot of free resources. Ballooning driver should not influence performance(FUEL 6.1). Kind regards, Gleb Stepanov. On Fri, Jul 10, 2015 at 11:10 PM, Konstantin Danilov kdani...@mirantis.com wrote: ...spinning drive based on fio. splining drive. All tests are done with fio, here is a link on full test report - http://koder-ua.github.io/6.1GA/ephemeral_drive.html. Here is a link on report for same test, executed directly on HDD, used for ephemeral storage - http://koder-ua.github.io/6.1GA/compute_node_HDD.html. We use following version of QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.13). We are using QEMU Debian 2.0.0+dfsg-2ubuntu1.13. We have not used enviroment fully, so i guess there is not affection of balloning. There only one vm on this compute node, and there a lot of free resources. Ballooning driver should not influence performance(FUEL 6.1). On Fri, Jul 10, 2015 at 11:00 PM, Gleb Stepanov gstepa...@mirantis.com wrote: Hello, Warren. Yes, we use properly filled file on a single spinning drive based on fio. We use following version of QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.13). Your command has following output: virtio-blk-device.drive=drive virtio-blk-device.logical_block_size=blocksize virtio-blk-device.physical_block_size=blocksize virtio-blk-device.min_io_size=uint16 virtio-blk-device.opt_io_size=uint32 virtio-blk-device.bootindex=int32 virtio-blk-device.discard_granularity=uint32 virtio-blk-device.cyls=uint32 virtio-blk-device.heads=uint32 virtio-blk-device.secs=uint32 virtio-blk-device.serial=str virtio-blk-device.config-wce=on/off virtio-blk-device.scsi=on/off virtio-blk-device.x-iothread=iothread We have not used enviroment fully, so i guess there is not affection of balloning. Kind regards, Gleb Stepanov. On Fri, Jul 10, 2015 at 6:01 PM, Gleb Stepanov gstepa...@mirantis.com wrote: -- Forwarded message -- From: Gleb Stepanov gstepa...@mirantis.com Date: Wed, Jul 8, 2015 at 1:58 PM Subject: [nova] disk I/O perfomance To: openstack-operators@lists.openstack.org, openstack-...@lists.openstack.org Hello, all. We have measured disk I/O performance on openstack virtual machines with aid of FIO tool. We've tested performance on root dist drive device, test consists of write operationby 4kb blocks to file with size 90Gb (prefilled in advance). We use qcow2 image for vm, ephemeral drive and virtio driver. All configuration goes in attachment. There are some results: test 1 threads 1, 5, 10, 15, 20, 40 iops 72,58,49,60,94,72 test 2 threads 1, 5, 10, 15, 20, 40 iops 71,60,54,88,52,52 test 3 threads 1, 5, 10, 15, 20, 40 iops 71,49,58,51,128,130 test 4 threads 1, 5, 10, 15, 20, 40 iops 65,49,60,56,52,63 As it is shown performance degraded during increasing amount of threads, also deviation of results on 40 threads is very big. Have you any ideas how to explain performance behaviour? Kind regards, Gleb Stepanov. -- Kostiantyn Danilov aka koder.ua Principal software engineer, Mirantis skype:koder.ua http://koder-ua.blogspot.com/ http://mirantis.com ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [all] Setting epoch in setup.cfg??
Ian Cordasco wrote: On 7/10/15, 03:44, Thierry Carrez thie...@openstack.org wrote: Also you'll find that the various distros use different epoch values for the same software, because epoch are also used to cover local blunders in packaging and historical artifacts. That is why epochs should be local to each packaging system and specifying it upstream is imho counter-productive. So, unpopular opinion time, but I think we restrict ourselves way too much based on a false notion that the only people who consume OpenStack are consuming it via downstream packages. Joshua has pointed out a very real use case (deploying inside a virtual environment) and there are also cases where people build from source and will be (attempting) to upgrade from 2015.1.x to 11.0.0 or 8.0.0. Even if people only use PyPI as a way of determining version order, using epochs will be significantly better for them. Perhaps I'm too late to the discussion, but it also appears no other opinions were solicited for it, especially not from users or operators. Specifically, I'd like to understand why using a feature of PEP 440 to explicitly indicate a shift in version numbering is counter-productive. It seems like it would be very productive for people who aren't tightly integrated into the development process. By counter-productive, I meant: likely to generate more confusion than clarity. If you provide an epoch in the version and it doesn't match downstream packagers ones, it's hard to rely on it. That said, I can see your point: people who consume from pip would like to have epochs too, epoch-sanitized versioning should not be reserved to distros. What I want to avoid is releasing nova-2!12.0.0.0.tar.gz tarballs, because that would be ugly (and confusing, with distros all having their own idea of an epoch set as well). But I don't mind including an epoch= parameter in setup.cfg if that makes pip happier. Could you detail what your preferred system would look like ? -- Thierry Carrez (ttx) __ 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] Plethora of dbase migration questions...
Hi, Paul! This messages is OK. May be you can put a change on review in WIP status, that I will be able to check what is going on? I never have such problems with migrations in neutron-vpnaas repo. May be the problem is that database is already upgraded, was database cleaned before you run neutron-db-manage upgrade head? On Tue, Jul 7, 2015 at 11:35 PM, Paul Michali p...@michali.net wrote: Well, I can run the upgrade command, but it doesn't seem to be processing my new migration file. I have tried using upgrade with 'head', and with the HEAD file set to the previous version and to the new version. In both cases, I get these info messages twice: Context impl MySWLImpl. and Will assume non-transactional DDL. I put a import pdb; pdb.set_trace() in my migration file, but it never reaches that. What am I possibly missing? Regards, PCM On Tue, Jul 7, 2015 at 4:04 PM Paul Michali p...@michali.net wrote: I found the issue. The upgrade is looking for config to have [database] section and connection definition. If I use /etc/neutron/neutron.conf, then the neutron-db-manage runs. On Tue, Jul 7, 2015 at 3:38 PM Paul Michali p...@michali.net wrote: I have that change in the neutron repo that is being used with by this neutron-vpnaas repo. On Tue, Jul 7, 2015 at 3:12 PM Mike Bayer mba...@redhat.com wrote: On 7/7/15 1:28 PM, Paul Michali wrote: HEAD, head, 24f28869838b (my new file) all say the same thing. :( On Tue, Jul 7, 2015 at 12:34 PM Salvatore Orlando sorla...@nicira.com wrote: possibly I was wrong in mixing up git alembic. It should be upgrade head - lowercase. If that doesn't work there might some other issue lurking. Salvatore On 7 July 2015 at 17:44, Paul Michali p...@michali.net wrote: Salvatore, I changed head to the version before my new one, and then tried to upgrade and I see this: neutron-db-manage --config-file /opt/stack/neutron/etc/neutron.conf --service vpnaas upgrade HEAD Traceback (most recent call last): File /usr/local/bin/neutron-db-manage, line 10, in module sys.exit(main()) File /opt/stack/neutron/neutron/db/migration/cli.py, line 238, in main CONF.command.func(config, CONF.command.name) File /opt/stack/neutron/neutron/db/migration/cli.py, line 105, in do_upgrade run_sanity_checks(config, revision) File /opt/stack/neutron/neutron/db/migration/cli.py, line 229, in run_sanity_checks script_dir.run_env() File /usr/local/lib/python2.7/dist-packages/alembic/script.py, line 390, in run_env util.load_python_file(self.dir, 'env.py') File /usr/local/lib/python2.7/dist-packages/alembic/util.py, line 243, in load_python_file module = load_module_py(module_id, path) File /usr/local/lib/python2.7/dist-packages/alembic/compat.py, line 79, in load_module_py mod = imp.load_source(module_id, path, fp) File /opt/stack/neutron-vpnaas/neutron_vpnaas/db/migration/alembic_migrations/env.py, line 86, in module run_migrations_online() File /opt/stack/neutron-vpnaas/neutron_vpnaas/db/migration/alembic_migrations/env.py, line 67, in run_migrations_online engine = session.create_engine(neutron_config.database.connection) File /usr/local/lib/python2.7/dist-packages/oslo_db/sqlalchemy/engines.py, line 112, in create_engine url = sqlalchemy.engine.url.make_url(sql_connection) File /usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/url.py, line 186, in make_url return _parse_rfc1738_args(name_or_url) File /usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/url.py, line 235, in _parse_rfc1738_args Could not parse rfc1738 URL from string '%s' % name) sqlalchemy.exc.ArgumentError: Could not parse rfc1738 URL from string '' Any ideas what is wrong here? I'm going to guess this is the issue fixed by https://review.openstack.org/#/c/194197/ On Tue, Jul 7, 2015 at 10:05 AM Paul Michali p...@michali.net wrote: Yes, I wasn't using the --service option, so I suspect that is why my down_version was wrong. In talking with Akihiro, I added a check to PEP8 and made sure that it fails if head is wrong. It is: https://review.openstack.org/#/c/199082/ https://review.openstack.org/#/c/199082/ (of course that failed py27 - I've got to see if there was some recent breakage in vpn repo, again). Regarding the migration, one of the new columns may be None, but there must be at least one IP version entry (there is an existing test in VPN for using a router w/o an external IP set). Since the new code will rely on these new fields, I'd like to populate them as part of the migration. I think it would be more complicated to handle during operation. Does anyone have examples of how to do queries of objects, from the migration upgrade() code? Regards, PCM On Tue, Jul 7, 2015 at 9:02 AM Akihiro Motoki amot...@gmail.com wrote: 2015-07-07 21:39 GMT+09:00 Henry Gessau ges...@cisco.com ges...@cisco.com: On Tue,
Re: [openstack-dev] [Murano] Versioning of Murano packages and MuranoPL classes
Hi Gosha, Supporting versioning in existing backend will require us to re-implement the significant part of Artifact Repository in Murano API: we'll need to add versions and dependencies concepts into our model (which is already complicated and dirty enough), extend appropriate API calls etc. And all the efforts will be a waste of time once we finally migrate to Artifacts. Also, what do you mean by set by default? V3 API is experimental, but it is already merged into upstream Glance, so there is no problem with using it in Murano right away. -- Regards, Alexander Tivelkov On Fri, Jul 10, 2015 at 5:56 PM, Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: Hi Alex, Thank you for the great summary. I have a concern about item #8. Can we add an option to Murano to use previous storage engine rather then Glance v3? We need to make sure that v3 API in Glance is set by default before we do a hard dependency on it in Murano. Thanks Gosha On Fri, Jul 10, 2015 at 4:53 AM, Alexander Tivelkov ativel...@mirantis.com wrote: Hi folks, Ability to manage multiple versions of application packages and their dependencies was always an important item in Murano roadmap, however we still don't have a clear spec for this feature. Yesterday we hosted a small design session to come up with a plan on what can be done in Liberty timeframe to have proper versioning for MuranoPL classes and packages. Stan Lagun, Kirill Zaitsev and myself participated offline, some other muranoers joined remotely. Thanks to everybody who joined us. TL;DR: it turns out that now we have a clear plan which will allow us to achieve proper versioning of the packages and classes, and we'll try to implement the most important parts of it in Liberty. Here is the detailed outcome of the session: 1. We'll use the standard Semantic Versioning format ('Major.Minor.Patch[-dev-build.label[+metadata.label]]') to version our packages: changes which break backwards-compatibility should increment the major segment, non-breaking new features increment the minor segment and all non-breaking bugfixes increment the patch segment. The developers should be carefull with the new features part: if you add a new method to a class, it may be considered a breaking change if the existing subclasses of this class have the same method already declared. We still assume that such changes should lead to increment of 'minor' segment, however it is up to best judgement of developers in particular case: if the risk of such method override is really high it may worth to increment the 'major' segment. Proper guideline on the versioning rules will be published closer to L release. 2. A new field 'Version' is introduced into package manifest file which should define package version in complete semver format. The field itself is optional (so existing apps are not broken), if it is not specified the package is assumed to have version '0.0.0' 3. The existing 'Require' block of Application manifest will be used to specify the package dependencies. Currently it is a yaml-based dictionary, with the keys set to fully-qualified names of the dependency packages and the values set to the version of those dependencies. Currently this block is used only for integration with apps stored at apps.openstack.org. It is suggested to use this block in the deployment process as well, and extend its semantics. The version of the dependency specified there should also follow the semver notation, however it may be specified in the shortened format, i.e. without specifying the 'patch' or 'patch' and 'minior' components. In this case the dependency will be specified as a range of allowed versions. For example, a dependency version 1.2 will mean a (1.2.0 = version 1.3) range. If the version of a dependency is not specified (like in this existing app - [1]) then we assume the version 0 - i.e. the last available pre-release version of a package. 4. Murano core library is also a package which has its own version. The current one is assumed to have a version 0.1.0, the one which is going to be released in L will be probably called 0.2.0. The lib is still quickly evolving, so we are not releasing a 1.0.0 until we are sure that we are not going to have any breaking changes anytime soon. As with any other package it will be possible to have several versions of the Core Library installed in Murano at the same moment of time. 5. There is no mandatory need to add the the dependency on the core library to the Requires block of each application, as it is added there implicitly. However, this implicit dependency will have a version 0 - i.e. will reference the latest pre-release version of the Core Library available. So it is still better to pin the core library requirement to a particular
Re: [openstack-dev] [Fuel][Fuel-Packaging][Fuel-CI][Fuel-Infra] How to Deal with CI Failures Induced by Libraries Requirements Drift
Vladimir, The failures you are referring to is purely test-related failures. They don't affect the code in production in any way, as far as I can see. All the same, production code won't be affected by pinning versions of test-requirements in the stable/* branches of the product and test suits. -Oleg On Mon, Jul 13, 2015 at 12:34 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: Oleg The problem here is that you have this code released and it is running in production - how are you going to fix this? Pin requirements and deal with dependency hell? Seriously, it is much easier to deal with explicitly frozen mirror which is created by one 'pip install ' run than to play with implicit transitive dependencies. On Mon, Jul 13, 2015 at 11:58 AM, Oleg Gelbukh ogelb...@mirantis.com wrote: Some comments inline. On Mon, Jul 13, 2015 at 9:24 AM, Bartlomiej Piotrowski bpiotrow...@mirantis.com wrote: Freezing every moving part is complete overkill and puts a heavy burden on devops team as well as infra itself. The fix couldn't be more simple: just put upper bounds in requirements. 1) if there is a new conflicting version, you need to set this upper-bound, thus you need to modify bits which get released It should be done as part of hard code freeze. As I understand, in this cases it is not code dependencies that cause misfunction, but dependencies of tests. This can be fixed by pinning test-requirements. We can do this any time, as it does not affect users. 2) you are actually testing your code by linking it with libraries which are different from those that users are really using when running your code Packages dependencies should reflect these set in requirements. 3) even if you specify an upper bound (or even fix the version) for this particular library, you may still fetch its newer dependency implicitly (by traversing indirect dependencies) with which you will be linking your libraries and which will actually be different from the code that you (and your users) use This can be actually said about anything, including base system Fuel is running. We simply do not support such setups. That's why we should run CI and nightly builds on stable branches. It catches exactly this type of issues. 4) you may also break production installation if you fix some library version as it may not exist in the code bundle which gets delivered to your users as a set of package See 2. Again, if something in code deps breaks our stable branch, we must learn it as soon as possible and fix it there. However, in this case it ist the test requirements failure, and it should pinned in 'test-requirements.txt' or in requirements of our test suits. -- Best regards, Oleg Gelbukh BP __ 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 -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.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 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] [Sahara] [QA] [tests coverage] Can we add CI job to control the unit tests coverage?
Hi, here is the commit on review: https://review.openstack.org/#/c/200433 We already added non-voting job in infra repository, need to merge this script. On Fri, Jul 3, 2015 at 1:29 PM, Anastasia Kuznetsova akuznets...@mirantis.com wrote: Boris, thanks for an explanation! I will take a closer look at the cover.sh script. On Fri, Jul 3, 2015 at 12:07 AM, Boris Pavlovic bpavlo...@mirantis.com wrote: Anastasia, because new patch may not be just a new code, committer may delete something or fix typos in docsting, etc. This job compares amount of non covered lines (before and after patch). If you just remove code there will be less lines that should be covered so amount of non covered lines will be less or the same (if everything was covered before) Fixing typos in docstrings won't introduce new lines. Btw job allows you to introduce N (few) new lines that are not covered by unit tests that are uncovered in some cases. Best regards, Boris Pavlovic On Thu, Jul 2, 2015 at 10:46 AM, Anastasia Kuznetsova akuznets...@mirantis.com wrote: Hi Timur, Generally I think that it is a good idea to have a gate that will check whether new code is covered by unit tests or not. But I am not sure that this gate should be voting (if I understand you correct), because new patch may not be just a new code, committer may delete something or fix typos in docsting, etc. On Thu, Jul 2, 2015 at 8:15 PM, Timur Nurlygayanov tnurlygaya...@mirantis.com wrote: Hi all, I suggest to add CI job which will check the unit tests coverage for Sahara repository and will set -1 for commits with new code and without unit tests (if we have some degradation of tests coverage). This job successfully works for Rally project and it helps to organize the right code development process when developers write new unit tests for new functionality. we can just copy this job from Rally and start to use it for Sahara: Coverage control script: https://github.com/openstack/rally/blob/master/tests/ci/cover.sh Configuration file for coverage plugin (to exclude code which shouldn't be affected): https://github.com/openstack/rally/blob/master/.coveragerc Example of job in infra repository: https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L4088 I expect that it will help to increase the tests coverage by unit tests. Do we have any objections? -- Timur, Senior QA Engineer OpenStack Projects Mirantis Inc __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Anastasia Kuznetsova __ 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 -- Best regards, Anastasia Kuznetsova __ 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 -- Timur, Senior QA Engineer OpenStack Projects Mirantis Inc __ 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] Migrate an instance from one compute host to another compute host.
HI all, I am trying to migrate an instance from one host to another . When I try using nova migrate SERVER TARGET_HOST , its saying that the computes are having any shared data path. TIA Regards Shanker DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [Fuel][Fuel-Packaging][Fuel-CI][Fuel-Infra] How to Deal with CI Failures Induced by Libraries Requirements Drift
Some comments inline. On Mon, Jul 13, 2015 at 9:24 AM, Bartlomiej Piotrowski bpiotrow...@mirantis.com wrote: Freezing every moving part is complete overkill and puts a heavy burden on devops team as well as infra itself. The fix couldn't be more simple: just put upper bounds in requirements. 1) if there is a new conflicting version, you need to set this upper-bound, thus you need to modify bits which get released It should be done as part of hard code freeze. As I understand, in this cases it is not code dependencies that cause misfunction, but dependencies of tests. This can be fixed by pinning test-requirements. We can do this any time, as it does not affect users. 2) you are actually testing your code by linking it with libraries which are different from those that users are really using when running your code Packages dependencies should reflect these set in requirements. 3) even if you specify an upper bound (or even fix the version) for this particular library, you may still fetch its newer dependency implicitly (by traversing indirect dependencies) with which you will be linking your libraries and which will actually be different from the code that you (and your users) use This can be actually said about anything, including base system Fuel is running. We simply do not support such setups. That's why we should run CI and nightly builds on stable branches. It catches exactly this type of issues. 4) you may also break production installation if you fix some library version as it may not exist in the code bundle which gets delivered to your users as a set of package See 2. Again, if something in code deps breaks our stable branch, we must learn it as soon as possible and fix it there. However, in this case it ist the test requirements failure, and it should pinned in 'test-requirements.txt' or in requirements of our test suits. -- Best regards, Oleg Gelbukh BP __ 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] [Fuel][Fuel-Packaging][Fuel-CI][Fuel-Infra] How to Deal with CI Failures Induced by Libraries Requirements Drift
Dima You have a very valid point, but the is a problem here - by doing it this way we are breaking developers' workflow which is based on using such repositories as pypi, rubygem, etc. If you convince developers (and I guess not only Fuel ones as we are moving towards community engagement) to switch their workflow - I have no objections. Bartek Actually, what we are doing is that we are freezing almost all the packages (except for upstream linux maintenance updates that should not change ABIs) thus having this drift at least constrained somehow. And this is how you control your upper bounds - you just do not push anything new into it. Let me provide an example why your suggestion does not work. Imagine, we have Debian Sid repository configured for our installations (or use some other 3rd party not strictly controlled mirror). It will work fine until you push new oslo package which is conflicting with your stuff like keystone, for example. And what is more important - you have already released this keystone and you CANNOT control requirements of it, you were not able to set them when you were working on the release because there is actually no time machine. This means that you need either to disable this 3rd party repo or to freeze in some state or you will have the same problem as with eggs. On Mon, Jul 13, 2015 at 9:24 AM, Bartlomiej Piotrowski bpiotrow...@mirantis.com wrote: Freezing every moving part is complete overkill and puts a heavy burden on devops team as well as infra itself. The fix couldn't be more simple: just put upper bounds in requirements. 1) if there is a new conflicting version, you need to set this upper-bound, thus you need to modify bits which get released It should be done as part of hard code freeze. 2) you are actually testing your code by linking it with libraries which are different from those that users are really using when running your code Packages dependencies should reflect these set in requirements. 3) even if you specify an upper bound (or even fix the version) for this particular library, you may still fetch its newer dependency implicitly (by traversing indirect dependencies) with which you will be linking your libraries and which will actually be different from the code that you (and your users) use This can be actually said about anything, including base system Fuel is running. We simply do not support such setups. 4) you may also break production installation if you fix some library version as it may not exist in the code bundle which gets delivered to your users as a set of package See 2. BP __ 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 -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.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
Re: [openstack-dev] [neutron][lbaas] Radware unit test issues
Brandon, thank you. I’ve pushed a fix for this issue https://review.openstack.org/#/c/201044 Evg From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Friday, July 10, 2015 7:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron][lbaas] Radware unit test issues python's mock library had an update yesterday that exposed some issues with unit tests that are using the mock assert calls. The radware tests were using a method called assert_called_once, which actually is not a real assert method off a mock. assert_called_once_with is, though. However, before the update mock would allow this method to run as it allowed any method calls to be run. Now with the update, only actual assert methods can be used, so that broke these tests. Changing the method to something like self.assertEquals(1, mocked_object.call_count) failed as well because the call_count was not actually 1. As such, I've pushed up a review to skip these tests. It would be great if radware folks could fix these tests and unskip them as I didn't have the time to look into actually figuring out if the call count discrepancy is a real issue or not. https://review.openstack.org/#/c/200616/ Thanks, Brandon __ 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] Should we document the using of device:owner of the PORT ?
Hi all, The device:owner the port is defined as a 255 byte string, and is widely used now, indicating the use of the port. Seems we can fill it freely, and user also could update/set it from cmd line(port-update $PORT_ID --device_owner), and I don't find the guideline for using. What is its function? For indicating the using of the port, and seems horizon also use it to show the topology. And nova really need it editable, should we at least document all of the possible values into some guide to make it clear? If yes, I can do it. I got these using from the code(maybe not complete, pls point it out): From constants.py, DEVICE_OWNER_ROUTER_HA_INTF = network:router_ha_interface DEVICE_OWNER_ROUTER_INTF = network:router_interface DEVICE_OWNER_ROUTER_GW = network:router_gateway DEVICE_OWNER_FLOATINGIP = network:floatingip DEVICE_OWNER_DHCP = network:dhcp DEVICE_OWNER_DVR_INTERFACE = network:router_interface_distributed DEVICE_OWNER_AGENT_GW = network:floatingip_agent_gateway DEVICE_OWNER_ROUTER_SNAT = network:router_centralized_snat DEVICE_OWNER_LOADBALANCER = neutron:LOADBALANCER And from debug_agent.py DEVICE_OWNER_NETWORK_PROBE = 'network:probe' DEVICE_OWNER_COMPUTE_PROBE = 'compute:probe' And setting from nova/network/neutronv2/api.py, 'compute:%s' % instance.availability_zone Thanks all! /Yalei __ 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] [trove]Expose new API for monitoring
We have proposing the blueprint about exposing new API for monitoring in https://blueprints.launchpad.net/trove/+spec/expose-new-api-for-monitoring Looking forward to any discussion :) -- tobe from UnitedStack__ 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] Reading an updated port's fixed IPs in mech driver update_port_postcommit
Hi Neil On 07/10/2015 12:49 PM, Neil Jerram wrote: A pragmatic fix appears to be to explicitly requery the IPAllocation table, as you can see in the two commits here: https://github.com/Metaswitch/calico/commit/5512ce7dd50db414f161bddcef17b0846a1466ac https://github.com/Metaswitch/calico/commit/4ecaf3568af52ef9cc29662a3b94672540056f05 in the second commit you actually set the right context, using context instead of context._plugin_context. Why didn't you replace context._plugin_context everywhere in that file, I think that might fix the issue. cheers, Rossella __ 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] [magnum] The way magnum-conductor communicates with k8s master
Hi, all. Currently magnum-conductor can communicates with k8s master which has a floating ip in all-in-one deployment. But if magnum-conductor is not deployed on the neutron network node which has the br-ex, how can magnum-conductor communicate with k8s master. The magnum-conductor node then has no access to the k8s master. Another question: Magnum-conductor only communicate with k8s master, why k8s minion has a floating ip too? What is the floating ip of k8s minion used for? Looking forward to any discussion. -- Regrards, Wanghua __ 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] [CI] How to set a proxy for zuul.
Instead of it use reusable_node option. On Tue, Jul 14, 2015 at 9:12 AM, Tang Chen tangc...@cn.fujitsu.com wrote: Hi Abhishek, All, I found the problem. My /etc/zuul/layout/layout.yaml has the following config: jobs: - name: ^dsvm-tempest.*$ parameter-function: single_use_node But in _parseConfig() in zuul/scheduler.py, it failed to find single_use_node(). fname = config_job.get('parameter-function', None) if fname: func = config_env.get(fname, None) if not func: raise Exception(Unable to find function %s % fname) So projects section was not parsed. Does anyone know why ? Thanks. On 07/14/2015 10:54 AM, Tang Chen wrote: Hi Abhishek, I printed the self.layout.projects in zuul/scheduler.py, it is empty. So the project was not found. But I did do the jenkins-jobs --flush-cache update /etc/jenkins_jobs/config/ And I did configure openstack-dev/sandbox in layout.yaml. Do you have any idea what's wrong here ? Thanks. On 07/13/2015 05:58 PM, Tang Chen wrote: On 07/13/2015 04:35 PM, Abhishek Shrivastava wrote: Updating jobs using sudo jenkins-jobs --flush-cache update /etc/jenkins_jobs/config/. Also update the myvendor in examples.yaml Sorry, I updated the jobs, restart the whole machine. But it still doesn't work. By the way, there is no vendor in examples.yaml. It is still this error: Project openstack-dev/sandbox not found Anything else should I pay attention to? Thanks. On Mon, Jul 13, 2015 at 1:45 PM, Tang Chen tangc...@cn.fujitsu.com wrote: On 07/13/2015 03:50 PM, Abhishek Shrivastava wrote: Use tester or something, also are you updating the jobs or not? I used tester as my vendor. It doesn't work. And what do you mean by updating the jobs ? I built the noop-check-cimmunitication job once in Jenkins UI. Does it matter ? All the others are not touched. And referring to the error, Project openstack-dev/sandbox not found, it seems like somewhere the project name was wrong. right ? Thanks. On Mon, Jul 13, 2015 at 1:16 PM, Tang Chen tangc...@cn.fujitsu.com wrote: Hi Abhishek, Thanks for the quick reply. On 07/13/2015 03:16 PM, Abhishek Shrivastava wrote: Also check that Gearman is connecting or not through Jenkins UI. On Mon, Jul 13, 2015 at 12:45 PM, Abhishek Shrivastava abhis...@cloudbyte.com wrote: First of all, change the vendor to your vendor name in /etc/jenkins_jobs/config/projects.yaml file. Also, restart the zuul and zuul merger. I did the check. Gearman plugin works find. In Jenkins UI, I tested the connection, and it succeeded. And also, I restarted zuul and zuul merger every time I modified the yaml files. But it doesn't work. And the vendor, does that matter ? And what vendor name should I provide ? I cannot find any vendor info in my Gerrit service account profile. For example, is XXX OK ? Thanks. On Mon, Jul 13, 2015 at 12:29 PM, Tang Chen tangc...@cn.fujitsu.com wrote: Hi all, I have constructed my CI system. When I tested it with sandbox project, I posted a patch to Gerrit. https://review.openstack.org/201002 But I got this error in zuul scheduler: 2015-07-14 14:07:24,921 DEBUG zuul.Scheduler: Run handler awake 2015-07-14 14:07:24,921 DEBUG zuul.Scheduler: Fetching trigger event 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Processing trigger event TriggerEvent comment-added openstack-dev/sandbox master 201002,1 Verified:1 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Project openstack-dev/sandbox not found 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Run handler sleeping My /etc/zuul/layout/layout.yaml looks like this: projects: - name: openstack-dev/sandbox check: - noop-check-communication My /etc/jenkins_jobs/config/projects.yaml looks like this: - project: name: sandbox github-org: openstack-dev node: master vendor: myvendor jobs: - noop-check-communication - dsvm-tempest-full: node: 'devstack_slave || devstack-precise-check || d-p-c' And Jenkins master works fine. Does anyone know what is going on here ? Thanks. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Thanks Regards, * *Abhishek* *Cloudbyte Inc. http://www.cloudbyte.com* -- *Thanks Regards, * *Abhishek* *Cloudbyte Inc. http://www.cloudbyte.com* __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core
+1 from me. Paul reviews are always helpful and easily in the same number with the other Core members (108 reviews this cycle!). Additionally he has been helpful in testing the new Ansible pieces as well as pushing forward the source installation, both areas we need help in currently. Sam Yaple On Mon, Jul 13, 2015 at 9:40 PM, Steven Dake (stdake) std...@cisco.com wrote: Hey folks, I am proposing Paul Bourke for the Kolla core team. He did a fantastic job getting Kolla into shape to support multiple distros and from source/from binary installation. His statistics are fantastic including both code and reviews. His reviews are not only voluminous, but consistently good. Paul is helping on many fronts and I would feel make a fantastic addition to our core reviewer team. Consider my proposal to count as one +1 vote. Any Kolla core is free to vote +1, abstain, or vote –1. A –1 vote is a veto for the candidate, so if you are on the fence, best to abstain :) We require 3 core reviewer votes to approve a candidate. I will leave the voting open until July 20th UTC. If the vote is unanimous prior to that time or a veto vote is received, I’ll close voting and make appropriate adjustments to the gerrit groups. Regards -steve __ 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] version cap on libs
hi, what's the status of patches like this? https://review.openstack.org/#/c/173834/ we still haven't decided how to handle that? __ 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] How to use security-port in kilo?
Hi all, Recently I want to have a try of the feature security-port, but these is very few introduction. Could you give some help? Thank you. __ 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-operators] How to configure security-port feature in Kilo ?
Hi all, Recently I want to have a try of the feature security-port, but these is very few introduction. Could you give some help? Thank you. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [CI] How to set a proxy for zuul.
Hi Abhishek, I printed the self.layout.projects in zuul/scheduler.py, it is empty. So the project was not found. But I did do the jenkins-jobs --flush-cache update /etc/jenkins_jobs/config/ And I did configure openstack-dev/sandbox in layout.yaml. Do you have any idea what's wrong here ? Thanks. On 07/13/2015 05:58 PM, Tang Chen wrote: On 07/13/2015 04:35 PM, Abhishek Shrivastava wrote: Updating jobs using sudo jenkins-jobs --flush-cache update /etc/jenkins_jobs/config/. Also update the myvendor in examples.yaml Sorry, I updated the jobs, restart the whole machine. But it still doesn't work. By the way, there is no vendor in examples.yaml. It is still this error: Project openstack-dev/sandbox not found Anything else should I pay attention to? Thanks. On Mon, Jul 13, 2015 at 1:45 PM, Tang Chen tangc...@cn.fujitsu.com mailto:tangc...@cn.fujitsu.com wrote: On 07/13/2015 03:50 PM, Abhishek Shrivastava wrote: Use tester or something, also are you updating the jobs or not? I used tester as my vendor. It doesn't work. And what do you mean by updating the jobs ? I built the noop-check-cimmunitication job once in Jenkins UI. Does it matter ? All the others are not touched. And referring to the error, Project openstack-dev/sandbox not found, it seems like somewhere the project name was wrong. right ? Thanks. On Mon, Jul 13, 2015 at 1:16 PM, Tang Chen tangc...@cn.fujitsu.com mailto:tangc...@cn.fujitsu.com wrote: Hi Abhishek, Thanks for the quick reply. On 07/13/2015 03:16 PM, Abhishek Shrivastava wrote: Also check that Gearman is connecting or not through Jenkins UI. On Mon, Jul 13, 2015 at 12:45 PM, Abhishek Shrivastava abhis...@cloudbyte.com mailto:abhis...@cloudbyte.com wrote: First of all, change the vendor to your vendor name in /etc/jenkins_jobs/config/projects.yaml file. Also, restart the zuul and zuul merger. I did the check. Gearman plugin works find. In Jenkins UI, I tested the connection, and it succeeded. And also, I restarted zuul and zuul merger every time I modified the yaml files. But it doesn't work. And the vendor, does that matter ? And what vendor name should I provide ? I cannot find any vendor info in my Gerrit service account profile. For example, is XXX OK ? Thanks. On Mon, Jul 13, 2015 at 12:29 PM, Tang Chen tangc...@cn.fujitsu.com mailto:tangc...@cn.fujitsu.com wrote: Hi all, I have constructed my CI system. When I tested it with sandbox project, I posted a patch to Gerrit. https://review.openstack.org/201002 But I got this error in zuul scheduler: 2015-07-14 14:07:24,921 DEBUG zuul.Scheduler: Run handler awake 2015-07-14 14:07:24,921 DEBUG zuul.Scheduler: Fetching trigger event 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Processing trigger event TriggerEvent comment-added openstack-dev/sandbox master 201002,1 Verified:1 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Project openstack-dev/sandbox not found 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Run handler sleeping My /etc/zuul/layout/layout.yaml looks like this: projects: - name: openstack-dev/sandbox check: - noop-check-communication My /etc/jenkins_jobs/config/projects.yaml looks like this: - project: name: sandbox github-org: openstack-dev node: master vendor: myvendor jobs: - noop-check-communication - dsvm-tempest-full: node: 'devstack_slave || devstack-precise-check || d-p-c' And Jenkins master works fine. Does anyone know what is going on here ? Thanks. __ 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 -- * * *Thanks Regards, * *Abhishek*
Re: [openstack-dev] [magnum] The way magnum-conductor communicates with k8s master
Hi, Wanghua Currently magnum-conductor can communicates with k8s master which has a floating ip in all-in-one deployment. But if magnum-conductor is not deployed on the neutron network node which has the br-ex, how can magnum-conductor communicate with k8s master. The magnum-conductor node then has no access to the k8s master. Currently this is a limitation of our architecture. Another question: Magnum-conductor only communicate with k8s master, why k8s minion has a floating ip too? What is the floating ip of k8s minion used for? I think, there is no reason. Historically, Our heat template come from larsks/heat-kubernetes [1] template. larsks/heat-kubernetes provides floating ip to minion nodes, this is just a reason. [1]: https://github.com/larsks/heat-kubernetes Thanks -Yuanying __ 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] [CI] How to set a proxy for zuul.
Hi Abhishek, All, I found the problem. My /etc/zuul/layout/layout.yaml has the following config: jobs: - name: ^dsvm-tempest.*$ parameter-function: single_use_node But in _parseConfig() in zuul/scheduler.py, it failed to find single_use_node(). fname = config_job.get('parameter-function', None) if fname: func = config_env.get(fname, None) if not func: raise Exception(Unable to find function %s % fname) So projects section was not parsed. Does anyone know why ? Thanks. On 07/14/2015 10:54 AM, Tang Chen wrote: Hi Abhishek, I printed the self.layout.projects in zuul/scheduler.py, it is empty. So the project was not found. But I did do the jenkins-jobs --flush-cache update /etc/jenkins_jobs/config/ And I did configure openstack-dev/sandbox in layout.yaml. Do you have any idea what's wrong here ? Thanks. On 07/13/2015 05:58 PM, Tang Chen wrote: On 07/13/2015 04:35 PM, Abhishek Shrivastava wrote: Updating jobs using sudo jenkins-jobs --flush-cache update /etc/jenkins_jobs/config/. Also update the myvendor in examples.yaml Sorry, I updated the jobs, restart the whole machine. But it still doesn't work. By the way, there is no vendor in examples.yaml. It is still this error: Project openstack-dev/sandbox not found Anything else should I pay attention to? Thanks. On Mon, Jul 13, 2015 at 1:45 PM, Tang Chen tangc...@cn.fujitsu.com mailto:tangc...@cn.fujitsu.com wrote: On 07/13/2015 03:50 PM, Abhishek Shrivastava wrote: Use tester or something, also are you updating the jobs or not? I used tester as my vendor. It doesn't work. And what do you mean by updating the jobs ? I built the noop-check-cimmunitication job once in Jenkins UI. Does it matter ? All the others are not touched. And referring to the error, Project openstack-dev/sandbox not found, it seems like somewhere the project name was wrong. right ? Thanks. On Mon, Jul 13, 2015 at 1:16 PM, Tang Chen tangc...@cn.fujitsu.com mailto:tangc...@cn.fujitsu.com wrote: Hi Abhishek, Thanks for the quick reply. On 07/13/2015 03:16 PM, Abhishek Shrivastava wrote: Also check that Gearman is connecting or not through Jenkins UI. On Mon, Jul 13, 2015 at 12:45 PM, Abhishek Shrivastava abhis...@cloudbyte.com mailto:abhis...@cloudbyte.com wrote: First of all, change the vendor to your vendor name in /etc/jenkins_jobs/config/projects.yaml file. Also, restart the zuul and zuul merger. I did the check. Gearman plugin works find. In Jenkins UI, I tested the connection, and it succeeded. And also, I restarted zuul and zuul merger every time I modified the yaml files. But it doesn't work. And the vendor, does that matter ? And what vendor name should I provide ? I cannot find any vendor info in my Gerrit service account profile. For example, is XXX OK ? Thanks. On Mon, Jul 13, 2015 at 12:29 PM, Tang Chen tangc...@cn.fujitsu.com mailto:tangc...@cn.fujitsu.com wrote: Hi all, I have constructed my CI system. When I tested it with sandbox project, I posted a patch to Gerrit. https://review.openstack.org/201002 But I got this error in zuul scheduler: 2015-07-14 14:07:24,921 DEBUG zuul.Scheduler: Run handler awake 2015-07-14 14:07:24,921 DEBUG zuul.Scheduler: Fetching trigger event 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Processing trigger event TriggerEvent comment-added openstack-dev/sandbox master 201002,1 Verified:1 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Project openstack-dev/sandbox not found 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Run handler sleeping My /etc/zuul/layout/layout.yaml looks like this: projects: - name: openstack-dev/sandbox check: - noop-check-communication My /etc/jenkins_jobs/config/projects.yaml looks like this: - project: name: sandbox github-org: openstack-dev node: master vendor: myvendor jobs: - noop-check-communication - dsvm-tempest-full: node: 'devstack_slave || devstack-precise-check || d-p-c' And Jenkins master works fine. Does anyone know what is going on here ?
Re: [Openstack] Neutron notifiers error on instance delete
Hello Matt, The errors are shown in the neutron server log on our management node. The compute node logs are clean. Compute node: # nova-manage version 2014.1.2-1.el6 # neutron --version 2.3.4 # nova --version 2.17.0 Management Node: # nova-manage version 2014.1-4.el6 # neutron --version 2.3.4 # nova --version 2.17.0 Cheers, Chris -Original Message- From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] Sent: Tuesday, July 14, 2015 00:49 To: openstack@lists.openstack.org Subject: Re: [Openstack] Neutron notifiers error on instance delete On 7/13/2015 6:11 AM, Chris wrote: Hello, When deleting a instance by the openstack API (DELETE {tenant_id} /servers/{server_id}) we see the following error on the neutron server, the instance isn’t deleted and change to error status: 2015-07-06 13:00:31.084 45873 ERROR neutron.notifiers.nova [req-7cf6c8a7-15a2-4c7e-8a84-97e173697ab0 None] Failed to notify nova on events: [{'status': 'completed', 'tag': u'267d2fc6-8ccb-4e6a-b88b-9caa3f09ba83', 'name': 'network-vif-unplugged', 'server_uuid': u'1eb1b855-e8fd-4df0-840e-d5fae0b69dda'}] 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova Traceback (most recent call last): 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/neutron/notifiers/nova.py, line 187, in send_events 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova batched_events) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/novaclient/v1_1/contrib/server_exter nal_events.py, line 39, in create 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova return_raw=True) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/novaclient/base.py, line 152, in _create 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova _resp, body = self.api.client.post(url, body=body) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/novaclient/client.py, line 312, in post 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova return self._cs_request(url, 'POST', **kwargs) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/novaclient/client.py, line 298, in _cs_request 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova method, **kwargs) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/novaclient/client.py, line 268, in _time_request 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova resp, body = self.request(url, method, **kwargs) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/novaclient/client.py, line 262, in request 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova raise exceptions.from_response(resp, body, url, method) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova NotFound: No instances found for any event (HTTP 404) (Request-ID: req-63a9ba3f-f1d3-4c5f-ae94-e6a7b4e6bb15) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova 2015-07-06 13:00:31.130 45873 INFO neutron.wsgi [-] (45873) accepted ('10.121.36.25', 49882) Any help appreciated! Cheers, Chris ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack What version of nova and neutron are you running and are there errors in the nova-compute logs that the instance was running on? -- Thanks, Matt Riedemann ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core
On Tue, Jul 14, 2015 at 11:40 AM, Steven Dake (stdake) std...@cisco.com wrote: Hey folks, I am proposing Paul Bourke for the Kolla core team. He did a fantastic job getting Kolla into shape to support multiple distros and from source/from binary installation. His statistics are fantastic including both code and reviews. His reviews are not only voluminous, but consistently good. Paul is helping on many fronts and I would feel make a fantastic addition to our core reviewer team. Consider my proposal to count as one +1 vote. Any Kolla core is free to vote +1, abstain, or vote –1. A –1 vote is a veto for the candidate, so if you are on the fence, best to abstain :) We require 3 core reviewer votes to approve a candidate. I will leave the voting open until July 20th UTC. If the vote is unanimous prior to that time or a veto vote is received, I’ll close voting and make appropriate adjustments to the gerrit groups. Regards -steve +1 No hesitation, Paul's contribution have always been excellent. Martin __ 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] [magnum][bp] Power Magnum to run on metal withHyper
Thanks Adrian! Hi, all, Let me recap what is hyper and the idea of hyperstack. Hyper is a single-host runtime engine. Technically, Docker = LXC + AUFS Hyper = Hypervisor + AUFS where AUFS is the Docker image. Due to the shared-kernel nature of LXC, Docker lacks of the necessary isolation in a multi-tenant CaaS platform, and this is what Hyper/hypervisor is good at. And because of this, most CaaS today run on top of IaaS: https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/388x275/e286dea1266b46c1999d566b0f9e326b/iaas.png Hyper enables the native, secure, bare-metal CaaS https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/395x244/828ad577dafb3f357e95899e962651b2/caas.png From the tech stack perspective, Hyperstack turns Magnum o run in parallel with Nova, not running on atop. Best, Peng -- Original -- From: Adrian Ottoadrian.o...@rackspace.com; Date: Tue, Jul 14, 2015 07:18 AM To: OpenStack Development Mailing List (not for usage questions)openstack-dev@lists.openstack.org; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Team, I woud like to ask for your input about adding support for Hyper in Magnum: https://blueprints.launchpad.net/magnum/+spec/hyperstack We touched on this in our last team meeting, and it was apparent that achieving a higher level of understanding of the technology before weighing in about the directional approval of this blueprint. Peng Zhao and Xu Wang have graciously agreed to respond to this thread to address questions about how the technology works, and how it could be integrated with Magnum. Please take a moment to review the blueprint, and ask your questions here on this thread. Thanks, Adrian Otto On Jul 2, 2015, at 8:48 PM, Peng Zhao p...@hyper.sh wrote: Here is the bp of Magnum+Hyper+Metal integration: https://blueprints.launchpad.net/magnum/+spec/hyperstack Wanted to hear more thoughts and kickstart some brainstorming. Thanks, Peng - Hyper - Make VM run like Container __ 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] Cross-Project meeting, Tue July 14th, 21:00 UTC
Dear PTLs, cross-project liaisons and anyone else interested, We'll have a cross-project meeting today at 21:00 UTC, with the following agenda: * Team announcements (horizontal, vertical, diagonal) * (OpenStack spec) Replace eventlet + monkey-patching with ?? [1] * (OpenStack spec) starting discussion spec for Service Catalog updates [2] * Open Discussion [1] https://review.openstack.org/#/c/164035 [2] https://review.openstack.org/#/c/181393 If you're from an horizontal team (Release management, QA, Infra, Docs, Security, I18n...) or a vertical team (Nova, Swift, Keystone...) and have something to communicate to the other teams, feel free to abuse the relevant sections of that meeting and make sure it gets #info-ed by the meetbot in the meeting summary. See you there ! For more details on this meeting, please see: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting -- Thanks, Nikhil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [keystone] the status of ec2 api
Hi Keystone team, Now the test of ec2 credentials[1] is been proposed to Tempest, and I'd like to know current situation of ec2 api on Keystone as a Tempest reviewer. On Nova instead, ec2 api is deprecated in Nova and the standalone service of ec2 api is separated from Nova to https://github.com/stackforge/ec2-api . As the result, ec2 api tests of Nova are defined as thirdparty and these tests don't run on normal checks/gates on the gate. If ec2 api is deprecated on Keystone side also, it seems better to define these tests as thirdparty. That is a reason why I'd like to know current situation of Keystone ec2 api. Thanks Ken Ohmichi --- [1]: https://review.openstack.org/#/c/194584 __ 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] Adding results to extension callbacks (ml2 port_update ext handling).
Inline reply (I've added to CC relevant people for ml2/plugin.py port_update extension handing -via git blame-) as they probably have an opinion here (specially the last two options). Kevin Benton wrote: This sounds like a lot of overlap with the dict extend functions. Why weren't they adequate for the QoS use case? Let me explain, I believe Mike exceeded the proposal with AFTER_READ, that's not the plan, even if we could do as he proposed, AFTER_READ dict extension is just a temporary workaround until we have a separate explicit api @armax is working on. Making explicit that your service is going to extend resources, and handled that in an ordered way is a good thing. Afterwards, the source of this review has came from ML2 implementation of AFTER_CREATE/AFTER_UPDATE notification for ports/nets. Let me explain: As a decoupled, mixinless service extending core resources, we need to do two things: 1) Extending the core resources as other extensions would do, adding stuff to the port/network dicts, here's where it comes the current AFTER_READ dict extension, and future API making that more explicit and more controlled. 2) Verifying the extended values we receive on core resources, by registering to BEFORE_* callbacks. For example, if a tenant is trying to use a qos_profile_id he doesn't have access to, or that doesn't exist, we can cancel the operation by throwing an exception. We need to extend the notifications for ports and networks, as that's not notified currently. Mike will work on that too in a separate patch. 3) Taking the finally extended values and store associations in database (AFTER_UPDATE/AFTER_CREATE) so any later reads of the port/network will get the right qos_profile_later in after read. We have found that AFTER_CREATE/AFTER_UPDATE happens at plugin level (neutron/plugins/ml2/plugin.py / update_port) and that information passed down is very brief to our case (basically a None port if no ml2-know attribute is changed), and ml2 has to be aware of every single extension. Here there are two options: a) we make ml2 also aware of qos_profile_id changes, complicating the business logic down there, or... b) we send the AFTER_CREATE/UPDATE events, and we listen to the callback listeners to such notification, and they will tell us if there's any relevant field which must be propagated down to agents. Then it's up to the agents to use such field or not. Mike's patch proposal is in the direction of (b), he's a long term thinker, I was proposing him to just go (a) for now, but let's discuss and find what's more right. On Mon, Jul 13, 2015 at 7:58 AM, Mike Kolesnikmkole...@redhat.com wrote: Hi, I sent a simple patch to check the possibility to add results to callbacks: https://review.openstack.org/#/c/201127/ This will allow us to decouple the callback logic from the ML2 plugin in the QoS scenario where we need to update the agents in case the profile_id on a port/network changes. It will also allow for a cleaner way to extend resource attributes as AFTER_READ callbacks can return a dict of fields to add to the original resource instead of mutating it directly. Please let me know what you think of this idea. Regards, Mike __ 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] [Sahara] Questions about how Sahara use trust ?
On 07/13/2015 09:40 PM, Li, Chen wrote: Hi mike, Thanks, this is very helpful. Summary: 1. The purpose of admin user proxy user are the same = to work without user's own username password. sort of, the proxy user is to work without the user's credentials, whereas the admin user needs a trust to operate on the user's project resources (clusters). 2. For transient cluster, what sahara need is to be able to operate. correct. 3. For swift access , using user's own credentials is not safe. Because the credentials is not used by sahara only, it will appear in user space (on the cluster nodes) at end. Using admin user is silly, doesn't gain any benefit, but create a more huge risk. correct. = proxy user must(better to) use proxy user, for security reason. = transient cluster can work both way, but proxy user introduce extra effect which is not nessary, so admin user is enough. i would say that is accurate. mike __ 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] version cap on libs
Well FWIW I think that that should go ahead: we have no constraints mechanism to keep to known-good versions for kilo, and the minimum version bump was explains in the requirements repo when it was proposed. On 14 July 2015 at 17:10, Takashi Yamamoto yamam...@midokura.com wrote: hi, what's the status of patches like this? https://review.openstack.org/#/c/173834/ we still haven't decided how to handle that? __ 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 -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ 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] [magnum] The way magnum-conductor communicates with k8s master
From: OTSUKA, Motohiro yuany...@oeilvert.orgmailto:yuany...@oeilvert.org Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, July 13, 2015 at 8:11 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [magnum] The way magnum-conductor communicates with k8s master Hi, Wanghua Currently magnum-conductor can communicates with k8s master which has a floating ip in all-in-one deployment. But if magnum-conductor is not deployed on the neutron network node which has the br-ex, how can magnum-conductor communicate with k8s master. The magnum-conductor node then has no access to the k8s master. Currently this is a limitation of our architecture. The floating IP is a public routed network, so it should be able to communicate in a properly setup cloud. Another question: Magnum-conductor only communicate with k8s master, why k8s minion has a floating ip too? What is the floating ip of k8s minion used for? I think, there is no reason. Historically, Our heat template come from larsks/heat-kubernetes [1] template. larsks/heat-kubernetes provides floating ip to minion nodes, this is just a reason. The minion floating ips are needed to access the micro-service front ends from the internet. Regards -steve [1]: https://github.com/larsks/heat-kubernetes Thanks -Yuanying __ 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] [murano] [congress] Congress needs to fetch environments from all tenants.
Hi Tim, The change was already merged to master. Withe next release of python-muranoclient it can be used in Congress. Regards Filip On 07/08/2015 03:57 PM, Tim Hinrichs wrote: There are two things to remember here. 1) When you configure the Congress datasource driver to talk to Murano, you choose which user rights Congress should use. If you need to get all of the tenants data, you want to choose an admin user for the Murano driver. Personally I always use admin users so that I can write policy over everything. Typically we think of Congress as an admin tool. 2) As you point out, if the Murano driver doesn't provide all_tenants=true argument when it makes the API call into Murano, it won't get all the data for all the tenants; it'll only get the data for the user you provided in (1). Ideally whether all_tenants=true would be a datasource configuration option, but it's not today. The datasource drivers I've looked at all use all_tenants=true. Tim On Wed, Jul 8, 2015 at 5:16 AM Kirill Zaitsev kzait...@mirantis.com mailto:kzait...@mirantis.com wrote: 1) This does raise a security concern. We can however cover it with a separate policy-based permission, that would check if a user can view all tenants. nova seem to do so, see: https://github.com/openstack/nova/blob/4209d0140774adf3e162b7bde3cbd6b417065dd5/etc/nova/policy.json#L13 2) Will give it some thought, but it does seem like an ok practice. -- Kirill Zaitsev Murano team Software Engineer Mirantis, Inc On 8 Jul 2015 at 14:44:51, Filip Blaha (filip.bl...@hp.com mailto:filip.bl...@hp.com) wrote: Hi all, I started implement bp [1]. Problem is that congress needs data about environments from all tenants but murano API lists only environments of user's current tenant. We decided to ipmplement it similarly like listing servers in nova where is query parameter all_tenants=true for that (user must be admin) I have 2 questions about that: 1) Are there any security concerns about this approach? 2) Has someone better idea how to implement this? [1] https://blueprints.launchpad.net/murano/+spec/murano-api-all-tenants-search Regards Filip __ 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 __ 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 __ 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] [puppet] weekly meeting #42
Hello Puppet masters! Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC in #openstack-meeting-4: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150714 Please add additional items you'd like to discuss. If our schedule allows it, we'll make bug triage during the meeting. See you there! -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ 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] Time to remove Python2.6 jobs from master
Excerpts from Jeremy Stanley's message of 2015-07-13 11:57:35 +: On 2015-07-13 10:08:16 +0200 (+0200), Ihar Hrachyshka wrote: clients and oslo libraries still maintain their py26 for a reason: decision to drop py26 was for server projects only. Yes, that decision was made at a time when our server projects had stable branches, but our clients and shared libraries did not. My recollection is that server projects only was a proxy for only projects with stable branches. Now that we have stable branches of, say, python-novaclient where we can backport juno-relevant security fixes, people on 2.6-only platforms who want to install and run python-novaclient from PyPI can use the stable/juno version (though I'll admit that finding which version works with 2.6 may be a tricky proposition for a consumer who is unaware of this situation). Yes, that's my recollection, too. I'm also a bit worried about the PyPI situation, since pip doesn't automatically detect that a version of a package is incompatible with the current version of python. The etherpad Dims linked to [1] proposes looking at the PyPI stats for client downloads. If those look relatively low, I would feel more confident in dropping 2.6 support in the master branch of the clients, with major version updates to indicate that. On the other hand, how much longer will we be supporting Juno? A matter of months, right? Doug [1] https://etherpad.openstack.org/p/juno-cross-project-future-of-python __ 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] Adding results to extension callbacks
Hi, I sent a simple patch to check the possibility to add results to callbacks: https://review.openstack.org/#/c/201127/ This will allow us to decouple the callback logic from the ML2 plugin in the QoS scenario where we need to update the agents in case the profile_id on a port/network changes. It will also allow for a cleaner way to extend resource attributes as AFTER_READ callbacks can return a dict of fields to add to the original resource instead of mutating it directly. Please let me know what you think of this idea. Regards, Mike __ 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][upgrades] Potential issues when performing Neutron upgrades
On 07/13/2015 04:09 AM, Kevin Benton wrote: because you won't have to run Neutron agents on compute nodes anymore. How will upgrades work for OVN? We haven't written anything down yet, but here's what I expect. Right now we're still changing the db schema however is needed without messing with versioning. As we get to production ready, I expect we'll start being strict about only making backwards compatible ovsdb schema changes to make upgrades easier. There are 2 central components - ovn-northd and ovsdb-server - that would be upgraded first, which I would expect to be done at the same time as upgrading your Neutron control plane. As long as any ovsdb schema changes are backwards compatible, you could do rolling-upgrades of ovn-controller on compute or network nodes. -- Russell Bryant __ 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] Time to remove Python2.6 jobs from master
On 7/13/2015 6:57 AM, Jeremy Stanley wrote: On 2015-07-13 10:08:16 +0200 (+0200), Ihar Hrachyshka wrote: clients and oslo libraries still maintain their py26 for a reason: decision to drop py26 was for server projects only. Yes, that decision was made at a time when our server projects had stable branches, but our clients and shared libraries did not. My recollection is that server projects only was a proxy for only projects with stable branches. Now that we have stable branches of, say, python-novaclient where we can backport juno-relevant security fixes, people on 2.6-only platforms who want to install and run python-novaclient from PyPI can use the stable/juno version (though I'll admit that finding which version works with 2.6 may be a tricky proposition for a consumer who is unaware of this situation). Taking python-novaclient as an example, there is still a gating py26 job on that project, so it still works. If/when we drop py26 support for a client, we could tag that commit and then people wanting to use the client on py26 could build a package from before that tag and then lay down whatever other patches they needed. Tempest is already sort of doing some things like this with tagging milestones due to the branchless nature of Tempest, so it seems the same idea could be carried over to the clients in cases like this. -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Versioning of Murano packages and MuranoPL classes
On Mon, Jul 13, 2015 at 2:19 AM, Alexander Tivelkov ativel...@mirantis.com wrote: Hi Gosha, Supporting versioning in existing backend will require us to re-implement the significant part of Artifact Repository in Murano API: we'll need to add versions and dependencies concepts into our model (which is already complicated and dirty enough), extend appropriate API calls etc. And all the efforts will be a waste of time once we finally migrate to Artifacts. Also, what do you mean by set by default? V3 API is experimental, but it is already merged into upstream Glance, so there is no problem with using it in Murano right away. This is exactly why I have these concerns. I wonder how much customers will use experimental API in production. I just don't want to add extra block on Murano adoption way. -- Regards, Alexander Tivelkov On Fri, Jul 10, 2015 at 5:56 PM, Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: Hi Alex, Thank you for the great summary. I have a concern about item #8. Can we add an option to Murano to use previous storage engine rather then Glance v3? We need to make sure that v3 API in Glance is set by default before we do a hard dependency on it in Murano. Thanks Gosha On Fri, Jul 10, 2015 at 4:53 AM, Alexander Tivelkov ativel...@mirantis.com wrote: Hi folks, Ability to manage multiple versions of application packages and their dependencies was always an important item in Murano roadmap, however we still don't have a clear spec for this feature. Yesterday we hosted a small design session to come up with a plan on what can be done in Liberty timeframe to have proper versioning for MuranoPL classes and packages. Stan Lagun, Kirill Zaitsev and myself participated offline, some other muranoers joined remotely. Thanks to everybody who joined us. TL;DR: it turns out that now we have a clear plan which will allow us to achieve proper versioning of the packages and classes, and we'll try to implement the most important parts of it in Liberty. Here is the detailed outcome of the session: 1. We'll use the standard Semantic Versioning format ('Major.Minor.Patch[-dev-build.label[+metadata.label]]') to version our packages: changes which break backwards-compatibility should increment the major segment, non-breaking new features increment the minor segment and all non-breaking bugfixes increment the patch segment. The developers should be carefull with the new features part: if you add a new method to a class, it may be considered a breaking change if the existing subclasses of this class have the same method already declared. We still assume that such changes should lead to increment of 'minor' segment, however it is up to best judgement of developers in particular case: if the risk of such method override is really high it may worth to increment the 'major' segment. Proper guideline on the versioning rules will be published closer to L release. 2. A new field 'Version' is introduced into package manifest file which should define package version in complete semver format. The field itself is optional (so existing apps are not broken), if it is not specified the package is assumed to have version '0.0.0' 3. The existing 'Require' block of Application manifest will be used to specify the package dependencies. Currently it is a yaml-based dictionary, with the keys set to fully-qualified names of the dependency packages and the values set to the version of those dependencies. Currently this block is used only for integration with apps stored at apps.openstack.org. It is suggested to use this block in the deployment process as well, and extend its semantics. The version of the dependency specified there should also follow the semver notation, however it may be specified in the shortened format, i.e. without specifying the 'patch' or 'patch' and 'minior' components. In this case the dependency will be specified as a range of allowed versions. For example, a dependency version 1.2 will mean a (1.2.0 = version 1.3) range. If the version of a dependency is not specified (like in this existing app - [1]) then we assume the version 0 - i.e. the last available pre-release version of a package. 4. Murano core library is also a package which has its own version. The current one is assumed to have a version 0.1.0, the one which is going to be released in L will be probably called 0.2.0. The lib is still quickly evolving, so we are not releasing a 1.0.0 until we are sure that we are not going to have any breaking changes anytime soon. As with any other package it will be possible to have several versions of the Core Library installed in Murano at the same moment of time. 5. There is no mandatory need to add the the dependency on the core library to the Requires
[openstack-dev] global-requirements sync not happening on stable/kilo? reqs check job busted?
From what I can tell, nova never got a global-requirements sync update for this change on stable/kilo: https://review.openstack.org/#/c/200493/ We need that so we don't have to try and do it manually: https://review.openstack.org/#/c/200880/ Which is apparently busted in the gate-nova-requirements job: http://logs.openstack.org/80/200880/1/check/gate-nova-requirements/461f83f/console.html#_2015-07-12_12_28_17_768 -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
On 2015-07-13 09:39:36 -0400 (-0400), Doug Hellmann wrote: [...] On the other hand, how much longer will we be supporting Juno? A matter of months, right? The reason it's being brought up again at this point is to ask whether it's more important that we keep master clients/libs working with 2.6 for several more months, or be able to push forward with our constraints overhaul between now and then. I'll be hard to have the necessary tooling in place before the liberty release if we can't actually use it before then (since that's roughly when juno EOL is scheduled). -- 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
Re: [openstack-dev] [nova][qa] turbo-hipster seems to be out to lunch
On 7/12/2015 1:50 AM, Joshua Hesketh wrote: Hey, Yes, sorry, I only discovered this yesterday. I should have updated the wiki page sooner but I've placed some details there now: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/kilo+topic:fix-th,n,z Basically the removal of migrate-flavor-data from master broke turbo-hipster and a few of the patches to make it work just missed the cut-off for kilo. As such they are backported here: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/kilo+topic:fix-th,n,z Turbo-hipster is now disabled, blocked on getting those in so any help reviewing would be appreciated. Thanks, Josh On Sat, Jul 11, 2015 at 9:09 AM, Matt Riedemann mrie...@linux.vnet.ibm.com mailto:mrie...@linux.vnet.ibm.com wrote: There are a lot of failures on nova changes since yesterday and rechecks today don't seem to be coming back (after rechecking several hours ago). Known issues? -- Thanks, Matt Riedemann __ 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 __ 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 Thanks for the summary. I'll work on getting these in today which includes getting the g-r sync and requirements jobs working again on stable/kilo. The fix for that is in the gate now and then we'll get the proper stuff working in nova stable/kilo to get your cherry picks in. -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [FUEL] Nailgun agent master freeze
At the moment everything is ready for moving fuel-web/bin/agent to a separate git repository. Please, be informed that all patches changing fuel-web/bin/agent that will be merged after this moment will need to be ported into the new nailgun-agent repository. Current source repository which will be imported to stackforge: https://github.com/warpc/fuel-nailgun-agent Please review: https://review.openstack.org/#/c/198053/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [Openstack] Rescinding the M name decision
On Jul 10, 2015, at 4:19 AM, Thierry Carrez thie...@openstack.org wrote: I think growing up is accepting the pain that comes with picking a good name, rather than sidestepping the issue. I’ve heard the phrase that there are only two hard problems in computer science, and naming is one of them. Just because it is hard is not a reason to avoid doing it. Sometimes the fact that it is hard is the biggest reason why we should do it, and make sure we do it right. We have a naming scheme, based on letters and the location. IMO, we should stick with that, we just need to go further down the list on due diligence, both from a copyright/trademark/legal perspective as well as cultural and other sensitivities that might not have been obvious from the beginning. YMMV. -- Brad Knowles b...@shub-internet.org LinkedIn Profile: http://tinyurl.com/y8kpxu signature.asc Description: Message signed with OpenPGP using GPGMail __ 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] global-requirements sync not happening on stable/kilo? reqs check job busted?
On 7/13/2015 9:01 AM, Matt Riedemann wrote: From what I can tell, nova never got a global-requirements sync update for this change on stable/kilo: https://review.openstack.org/#/c/200493/ We need that so we don't have to try and do it manually: https://review.openstack.org/#/c/200880/ Which is apparently busted in the gate-nova-requirements job: http://logs.openstack.org/80/200880/1/check/gate-nova-requirements/461f83f/console.html#_2015-07-12_12_28_17_768 Looks like we need this: https://review.openstack.org/#/c/198145/ -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] First Sprint proposal
I just closed the poll after one week. It will happen on Wed 9/2 – Fri 9/4. We'll work on the agenda during the following weeks. Best, On 07/06/2015 10:26 PM, Matt Fischer wrote: Operators mid-cycle is Aug 17-21 at a TBD location, I voted accordingly. Thanks. On Mon, Jul 6, 2015 at 12:09 PM, Emilien Macchi emil...@redhat.com mailto:emil...@redhat.com wrote: On 07/06/2015 02:05 PM, Matt Fischer wrote: I think this is a great idea. I'd like to get a firm date on the operators mid-cycle before I vote though. If it overlaps, we can add more slots. Feel free to ping me on IRC for that, I'll update the doodle. Thanks, On Mon, Jul 6, 2015 at 11:31 AM, Emilien Macchi emil...@redhat.com mailto:emil...@redhat.com mailto:emil...@redhat.com mailto:emil...@redhat.com wrote: Hi, I would like to organize our first sprint for contributing to our Puppet OpenStack modules. It will happen in Red Hat Montreal (Canada) office, during 3 days. If you're interested to participate, please find the slots that may work for you [1]. Any slot suggestion is welcome though. Also, please bring on the etherpad any topics we should work on together [2]. We will groom topics during a meeting and prepare the agenda before the sprint. [1] http://doodle.com/xk2sfgu4xsi4y6n4r46t7u9k [2] https://etherpad.openstack.org/p/puppet-liberty-mid-cycle Regards, -- Emilien Macchi __ 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://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 -- Emilien Macchi __ 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 __ 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 -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack-announce] End of life for managed stable/icehouse branches
On 2015-07-14 00:33:52 +0200 (+0200), Thomas Goirand wrote: [...] I believe I asked you about 10 times to keep these branches alive, so that distributions could work together on a longer support, even without a CI behind it. And the project consensus has seemed to disagree with this after careful discussion, each time it's brought up. Distributions collaborating upstream on stable branch support would entail helping keep those branches tested upstream. As a project we've consistently stated that publishing updates to stable branches without sufficient testing is an affront to our quality assurance stance. The final state of the upstream stable/icehouse branch, as with each previous stable branch all the way back to stable/diablo, is tagged in the repository so that you can construct your own continuation of stable/icehouse from the same point as needed. I have also asked for a private gerrit for maintaining the Icehouse patches after EOL. [...] I do apologize for not setting up a separate private Gerrit instance for embargoed security fix code reviewing. It would be a help to me and the rest of the VMT to have it, I simply haven't had the available time I'd hoped to be able to work out remaining implementation details for deploying and maintaining it. That said, its priority has decreased as the VMT is trying to get a little more cautious about only embargoing vulnerability reports that actually benefit enough from a brief advance notice to downstream stakeholders to offset the significant cost in efficiency of the embargo process (only a small amount of which is due to the tools we end up using for private code review). However, as I explained to you at the Liberty Design Summit after discussion with members of the infrastructure team, we're also not comfortable maintaining stable branches of projects in a private Gerrit instance any longer than we do in the normal public one, and would want to remove inactive branches from it at the same time their public counterparts reach end of life. Since I feel like I'm starting to repeat myself at this point, I'll leave it to others to continue the thread this time. If you're interested in overhauling the stable branch EOL process (I didn't design and plan it, I merely pull the levers and push the buttons), that discussion should involve the stable branch release managers and the rest of the release team along with the quality assurance team. -- Jeremy Stanley signature.asc Description: Digital signature __ 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 Miguel Angel Ajo for the Control Plane core team
Thanks Kevin and everybody for the positive feedback! :) It's a pleasure to work with so many awesome people. Best, Miguel Ángel, Kevin Benton wrote: It's been a week with no negative feedback. Welcome to the team Miguel! On Jul 7, 2015 5:22 AM, Ihar Hrachyshkaihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Oh yes! It was a bit weird that Miguel, while owning a feature branch, did not have a say in what is merged there. Now it should be more in line with his actual position in the project. Good work, Miguel! On 07/06/2015 01:02 PM, Kevin Benton wrote: Hello! As the Lieutenant of the built-in control plane[1], I am proposing to add Miguel Angel Ajo to the control plane core reviewer team. His review stats are inline with the other core reviewers[2], and his work on improving the stability/performance of the agents over the last year has been important in making the reference implementation reliable. Existing cores, please vote +1/-1 for his addition to the team. Cheers! 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.ht ml 2. http://stackalytics.com/report/contribution/neutron/30 http://stackalytics.com/report/contribution/neutron/60 http://stackalytics.com/report/contribution/neutron/90 -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVm7WcAAoJEC5aWaUY1u57RUoH/jIimjwrLqzzq8u0Ix25YGrR CQVkLGbE7j+LtzvKOcFSORp/Y/gwsJ6KF3B7NBqfh1C0fHx/uMVp/tf7/NhuthE0 7+gsMe3yn6oOraYCQHwEDHpxz6r+7dmMfhisknH5k7vsdnwNi5CrnXyr+knxrQ0L jjFvdi3F/+2ztV5LtPJLPoU72d81ATwEEFTH/9vUeFPlBu8okUuXRszPJCWR3MeL PrKeg5G6OH4b4GVC45Q7238rWB7uiwfFLILo9I8qwgJ/LZnKkK12bmk3tUgE3cqP BXxfuMKueJgOvRU0VPpWZwXicf2/pOmdUBv7uX+BeK9hPP5G9i8ITmFblB+doUk= =EuZs -END PGP SIGNATURE- __ 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
[openstack-dev] [puppet] puppet-designate POC implementation of virtualenv and docker support.
Last year I put together a virtualenv patch for the Designate puppet module, but the patch was too invasive of a change and too opinionated to be practical to merge. I've taken another shot at this with the approach of implementing well defined hooks for various phases of the module. This should allow external support for alternative ways of installing and running services (such as virtualenv, and docker). I think this patch is now mostly ready for some outside reviews (we'll be running the virtualenv support in production soon). The puppet-designate change to support this can be found here: https://review.openstack.org/#/c/197172/ The supporting puppet-designate_ext module can be found here: https://github.com/twc-openstack/puppet-designate_ext The basic approach is to split the module dependency chain into 3 phases: * install begin/end * config begin/end * service begin/end Each of these phases have a pair of corresponding anchors that are used internally for dependencies and notifications. This allows external modules to hook into this flow without having to change the module. For example, the virtualenv support will build the virtualenv environment between the designate::install::begin and designate::install::end anchors. Additionally, the virtualenv support will notify the designate::install::end anchor. This allows other resources to subscribe to this anchor without needing to know if the software is being installed as a package, virtualenv, or docker image. I think this approach could be applied mostly as is to at least some of the existing modules with similar levels of changes. For example, horizon, keystone heat would probably be fairly straightforward. I suspect this approach would need refinement for more complex services like neutron and nova. We would need to work out how to manage things like external packages that would still be needed if running a virtualenv based install, but probably not needed if running a docker based install. We would probably also want to consider how to be more granular about service notifications. I'd love to get some feedback on this approach if people have time to look it over. We're still trying to move away from using packages for service installs and I'd like to figure out how to do that without carrying heavyweight and fragile patches to the openstack puppet modules. __ 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] [kolla] Proposal for Paul Bourke for Kolla Core
Hey folks, I am proposing Paul Bourke for the Kolla core team. He did a fantastic job getting Kolla into shape to support multiple distros and from source/from binary installation. His statistics are fantastic including both code and reviews. His reviews are not only voluminous, but consistently good. Paul is helping on many fronts and I would feel make a fantastic addition to our core reviewer team. Consider my proposal to count as one +1 vote. Any Kolla core is free to vote +1, abstain, or vote –1. A –1 vote is a veto for the candidate, so if you are on the fence, best to abstain :) We require 3 core reviewer votes to approve a candidate. I will leave the voting open until July 20th UTC. If the vote is unanimous prior to that time or a veto vote is received, I’ll close voting and make appropriate adjustments to the gerrit groups. Regards -steve __ 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] Liberty SFE Request - Dynamic Policies
On 07/03/2015 08:36 AM, Samuel de Medeiros Queiroz wrote: Hi Thierry, Thanks for clarifying. A Spec Freeze Exception is what I was supposed to ask for. Rectifying: On behalf of the team working on the Dynamic Policies subject, I would like to ask for a *Spec Freeze Exception* in Liberty for it. This one is an important lead in to a lot of other work. Getting just this in to Liberty allows us to focus the remainder of the work on Dynamic policy inside Keystone. Please approve. Thanks, Samuel de Medeiros Queiroz Thierry Carrez wrote: samuel wrote: [...] On behalf of the team working on the Dynamic Policies subject, I would like to ask for a Feature Freeze Exception in Liberty for it. Liberty Feature Freeze is on September 3rd, so I doubt you need a feature freeze exception at this time. I suspect that would be a spec freeze exception or some other Keystone-specific freeze exception ? https://wiki.openstack.org/wiki/FeatureFreeze __ 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] xenserver and cinder
Hello, guys! We are currently making an installation of XS6.5+OS Juno (maybe we'll switch to kilo) We have 2 servers, controller has glance, nova and keystone, and compute vms have only nova-compute installed. We use local storage on each server, not shared one (this is important) We want to implement cinder service to manage volumes easily, but i can't understand how can we do it.XenAPINFSDriver is deprecated and isn't supported any more. The only solution i found so far is to create storage VM, give it some space and use this space for cinder volumes, and then mount it in VMs as ISCSI targets. And in the same time nova uses xenAPI to create and manage volumes when it creates instances. And what i want to make is to make cinder use Xenserver volumes both when nova creates VM and when i create volume with cinder. Without second level of abstraction. Can you tell me what are the best practices to use cinder for Xenservers with local storage? Regards, Ivan Derbenev ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [Ironic] how about those alternating meeting times?
On Mon, Jul 13, 2015 at 06:41:55PM +, Devananda van der Veen wrote: This is a much-overdue follow up to this poll, which got 17 responses. snip So, though it saddens me, I would like to propose that we change back to a single meeting time effective the week following our midcycle (Aug 10th). That will give folks two meetings in each timeslot between now and then to become aware of, and raise any issues with, this change. +1 for moving back to single meeting time, +2 for this being sad. I really wish we could include folks in those timezones, but it has proven to be mostly ineffective within the project. // jim Regards, Devananda On Mon, May 11, 2015 at 6:14 PM Michael Davies mich...@the-davies.net wrote: On Tue, May 12, 2015 at 9:08 AM, Ruby Loo rlooya...@gmail.com wrote: Maybe the question is better posed to those folks -- was it useful or not? And if not, why? Because the date/time still didn't work, or because not enough (or the right persons) weren't there so their issues of interest weren't discussed, or they wouldn't have attended anyway, or ? And if it was useful, for how many was it useful? (Devananda's poll will capture some of that info.) I found it useful - it's nice to be awake at meeting time :) There's certainly a subset of the team that I never overlap with now, which is a shame, but timezones present challenges for a geographically dispersed team. Previously the meeting was at 4:30am (or 5:30am depending upon daylight savings), which was quite hard, but I did make it most weeks. The new timeslot of 2:30am/pm (3:30am/pm) is certainly only achievable for me every other week (no surprises for guessing which one :) I think it's great that we try and accommodate contributors from all around the globe! Michael... -- Michael Davies mich...@the-davies.net Rackspace Cloud Builders Australia __ 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] [keystone] Liberty SFE Request -DynamicPolicies
I am a +1 on this as well. I agree with Guang Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Yee, Guang guang@hp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 07/13/2015 02:24 PM Subject:Re: [openstack-dev] [keystone] Liberty SFE Request - Dynamic Policies ++! Per my understanding, the work, and therefore the risks, are fairly compartmentalized. The upside is this will pave the way for a much richer authorization management system. Guang From: Adam Young [mailto:ayo...@redhat.com] Sent: Monday, July 13, 2015 10:15 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [keystone] Liberty SFE Request - Dynamic Policies On 07/03/2015 08:36 AM, Samuel de Medeiros Queiroz wrote: Hi Thierry, Thanks for clarifying. A Spec Freeze Exception is what I was supposed to ask for. Rectifying: On behalf of the team working on the Dynamic Policies subject, I would like to ask for a *Spec Freeze Exception* in Liberty for it. This one is an important lead in to a lot of other work. Getting just this in to Liberty allows us to focus the remainder of the work on Dynamic policy inside Keystone. Please approve. Thanks, Samuel de Medeiros Queiroz Thierry Carrez wrote: samuel wrote: [...] On behalf of the team working on the Dynamic Policies subject, I would like to ask for a Feature Freeze Exception in Liberty for it. Liberty Feature Freeze is on September 3rd, so I doubt you need a feature freeze exception at this time. I suspect that would be a spec freeze exception or some other Keystone-specific freeze exception ? https://wiki.openstack.org/wiki/FeatureFreeze __ 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] [Cinder] python-cinderclient functional tests
On 16:28 Jul 10, Ivan Kolodyazhny wrote: Hi Mike, Unfortunately, we don't get a lot of stats [1] because we don't run it often. I've added 'check experimental' comment to latest python-cinderclient review request to get more stats. Review request to make this voting: https://review.openstack.org/#/c/200522/ [1] http://graphite.openstack.org/render/?width=877height=548_salt=1436533755.887from=00%3A00_20150524until=23%3A59_20150710target=stats.zuul.pipeline.experimental.job.check-cinderclient-dsvm-functional.FAILUREtarget=stats.zuul.pipeline.experimental.job.check-cinderclient-dsvm-functional.SUCCESStarget=stats.zuul.pipeline.experimental.openstack.python-cinderclient.total_changestitle=check-cinderclient-dsvm-functional Add an agenda item to the next Cinder meeting. Sure there should be no objections. -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [Openstack-operators] FAiled to create instance wiht openstack nova network
Can somebody suggest me on the below? Thanks, Dev On Fri, Jul 10, 2015 at 4:32 PM, pra devOPS siv.dev...@gmail.com wrote: Hi I am running as root, Please find below the nova config file. ( I am using nova network) http://paste.openstack.org/show/363300/ Thanks, Dev On Fri, Jul 10, 2015 at 1:30 PM, matt m...@nycresistor.com wrote: root-wrap failed probably a config error. might want to post your nova configs with commenting out of passwords / service tokens. dnsmasq --strict-order --bind-interfaces --conf-file= --pid-file=/var/lib/nova/networks/nova-br100.pid --listen-address=192.168.22.1 --except-interface=lo --dhcp-range=set:demo-net,192.168.22.2,static,255.255.255.0,120s --dhcp-lease-max=256 --dhcp-hostsfile=/var/lib/nova/networks/nova-br100.conf --dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro --domain=novalocal --no-hosts --addn-hosts=/var/lib/nova/networks/nova-br100.hosts 2015-07-10 15:30:29.753 3044 TRACE oslo.messaging.rpc.dispatcher Exit code: 2 needs to run as root. exit code 2 is obviously pretty bad. so that NEEDs to be fixed. On Fri, Jul 10, 2015 at 3:25 PM, pra devOPS siv.dev...@gmail.com wrote: All: I get the following error when trying to create an instance in openstack icehouse centOS 7 on nova network. nova network logs and UI logs are pasted at: *http://paste.openstack.org/show/362706/ http://paste.openstack.org/show/362706/* Can somebdody give susggestiong? Thanks,Siva ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[OpenStack-Infra] [Infra] Meeting Tuesday July 14th at 19:00 UTC
Hi everyone, The OpenStack Infrastructure (Infra) team is having our next weekly meeting on Tuesday July 14th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is welcome to to add agenda items) Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend. In case you missed it or would like a refresher, the meeting minutes and full log from our last meeting are available here: Minutes: http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-07-07-19.02.html Minutes (text): http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-07-07-19.02.txt Log: http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-07-07-19.02.log.html -- Elizabeth Krumbach Joseph || Lyz || pleia2 ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [openstack-dev] [glance] Additions and removals for the glance-drivers team
On 7/9/15, 13:37, Flavio Percoco fla...@redhat.com wrote: Greetings, I'd like to propose Stuart Mclaren for the glance-drivers team. Stuart has a huge amount of knowledge about Glance's history, he knows the Glance codebase well and he also has experience in deploying and maintaning Glance production environments. Stuart has shown his interest in joining the team in the past but he's addition was put on-hold for other reasons. In the hope that Stuart is still willing to join the team, I'd like to propose him again hoping this time he'll be added. In addition to the above, I'd like to propose removing: - Arnaud Legendre - Mark Washenberger Arnaud and Mark, despite their amazing work in the past, are no longer contributing to Glance at all. I think it's time for us to thank them again for their contributions and to wish they'll join us again in the future. Cheers, Flavio -- @flaper87 Flavio Percoco +1 on adding Stuart if he still would like to join. +1 on removing Arnaud and Mark. While they contributed an immense amount of what Glance is today, they haven't been active in quite a while. If they ever do come back, I'd be in favor of adding them back to the drivers team though. __ 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] [Ironic] how about those alternating meeting times?
This is a much-overdue follow up to this poll, which got 17 responses. TL;DR: The poll indicated that most responders did not personally find the 0500 meeting helpful. Reviewing the meeting logs for the last six months shows significantly lower core attendance in those meetings. Informal feedback confirms both of these conclusions. As much as I want to be inclusive of contributors for whom the 1700GMT Monday meetings do not work, I feel that the 0500GMT Tuesday meetings have not been effective and would like to propose that we change back to a single meeting time. Longer summary: In that poll, I asked four questions to gauge both individual attendance and benefit, as well as perceived benefit to others. I think the results are quite interesting. (Note that every question had a free form choice as well, which I'm not tallying here) Were you able to attend the meetings? +4 Yes, I attended most or all of the metings -10 No. Because of the timing, I was only able to attend half of the meetings. Were the alternating times helpful to you personally? +5 Yes. I attended both Monday and Tuesday meetings and found this split helpful. -10 No. I was unable to attend half of the meetings and found some or all of them to be non-productive. Do you believe that alternating meeting times was helpful to the project overall, regardless of your own availability? +11 Yes - 4 No Do you think we should continue to split meeting times? +10 Yes -3 No In the freeform responses, I got suggestions to split out subteams (we've done this for the neutron integration work), as well as a few comments that DST impact was significant and preventing attendance to half the meetings, and suggestions to move the meeting a few hours this way or that way. Lately, I have missed several of the 0500GMT meetings due to tiredness, travel, or other things. I notice that very few of the core team are there, too (many thanks to Jim for consistently being there and leading it when I'm not). While I think it is important to have a meeting time that serves Haomeng and Ramki and Michael Davies (and everyone else in APAC), these meetings do not consistently have a majority of cores present and therefor can't reasonably make any decisions. And on the flip side, these impact the 1700GMT meetings in that those have lost a lot of momentum, seemingly because the US/EU regulars miss every other week. So, though it saddens me, I would like to propose that we change back to a single meeting time effective the week following our midcycle (Aug 10th). That will give folks two meetings in each timeslot between now and then to become aware of, and raise any issues with, this change. Regards, Devananda On Mon, May 11, 2015 at 6:14 PM Michael Davies mich...@the-davies.net wrote: On Tue, May 12, 2015 at 9:08 AM, Ruby Loo rlooya...@gmail.com wrote: Maybe the question is better posed to those folks -- was it useful or not? And if not, why? Because the date/time still didn't work, or because not enough (or the right persons) weren't there so their issues of interest weren't discussed, or they wouldn't have attended anyway, or ? And if it was useful, for how many was it useful? (Devananda's poll will capture some of that info.) I found it useful - it's nice to be awake at meeting time :) There's certainly a subset of the team that I never overlap with now, which is a shame, but timezones present challenges for a geographically dispersed team. Previously the meeting was at 4:30am (or 5:30am depending upon daylight savings), which was quite hard, but I did make it most weeks. The new timeslot of 2:30am/pm (3:30am/pm) is certainly only achievable for me every other week (no surprises for guessing which one :) I think it's great that we try and accommodate contributors from all around the globe! Michael... -- Michael Davies mich...@the-davies.net Rackspace Cloud Builders Australia __ 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] [Ironic] weekly subteam status report
Hi, Following is the subteam report for Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and formatted. Bugs (dtantsur) As of Mon, Jul 13 (diff with Jun 29) Open: 147 (-3). 6 new (+1), 52 in progress, 1 critical (+1), 10 high (-1) and 8 incomplete (-1) Nova bugs with Ironic tag: 24 (+1). 0 new, 0 critical, 0 high Neutron/Ironic work (jroll) still looking for spec reviews, have agreement within subteam - https://review.openstack.org/#/c/188528/ -- I've +2'd this with one follow-up needed - https://review.openstack.org/#/c/187829/ -- should be good to go, some nits to address I think Oslo (lintan) == Graduating fileutils, https://bugs.launchpad.net/ironic/+bug/1473815 Testing (adam_g/jlvillal) == https://review.openstack.org/#/c/166386/ (tempest microversion support) is still not merged, can we have more resources pointed at it? Inspector (dtansur) === ironic-inspector 2.0.0 released - http://lists.openstack.org/pipermail/openstack-announce/2015-July/000432.html - https://pypi.python.org/pypi/ironic-inspector/2.0.0 proposing to run inspector dsvm check in ironic experimental pipeline - https://review.openstack.org/#/c/198381/ Bifrost (TheJulia) = Considering a change over to utilizing simple-init for network configuration - https://review.openstack.org/#/c/200834/ Drivers == iRMC (naohirot) - https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z Status: Reactive (solicit for the final review and approval, started to write installation guide) - iRMC Virtual Media Deploy Driver bp/ipa-as-default-ramdisk Status: Active (spec and vendor passthru reviews are on going) - Enhance Power Interface for Soft Reboot and NMI - bp/enhance-power-interface-for-soft-reboot-and-nmi Status: Active (code review is on going) - iRMC out of band inspection - bp/ironic-node-properties-discovery Until next week, --ruby [0] https://etherpad.openstack.org/p/IronicWhiteBoard __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic] Reminder - midcycle Sprint in Seattle Aug 12 - 14
Hi all! Just dropping a reminder out here -- our midcycle is one month away! We're starting to jot down informal notes and plans on an etherpad here: https://etherpad.openstack.org/p/ironic-liberty-midcycle Please continue to use that to coordinate all the things. If you plan to attend, please make sure you're listed there and then go purchase a free ticket (one per person) on eventbrite so that I can coordinate with site facilities and send you any last-minute information about the event. https://www.eventbrite.com/e/openstack-ironic-sprint-august-2015-tickets-17533862254 Looking forward to seeing ya'll soon! -Devananda __ 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] [designate][lbaas][GSLB] IRC Meeting Tomorrow - 07/Jul/2015 @ 16:00 UTC
A quick reminder that we will be reconvening tomorrow at 16:00UTC in #openstack-meeting-4 to continue the API discussion. Thanks, Graham On 06/07/15 15:27, Hayes, Graham wrote: Hi All, I have put up an agenda for the meeting tomorrow: https://wiki.openstack.org/wiki/Meetings/GSLB It will be in #openstack-meeting-4 @ 16:00 UTC I sent around a strawman API doc last week - https://docs.google.com/document/d/1nw5jVn0hjmhlhkZJAohx-gqRkkbVhMMJ79Pogd0ysEk/edit?usp=sharing Can everyone have a read before the meeting tomorrow? Thanks, Graham Hayes __ 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] [puppet] new etherpad to track Puppet OpenStack CI work
On 07/13/2015 02:21 PM, Emilien Macchi wrote: It comes up some people are interested to help with Puppet OpenStack CI work, so here is an etherpad: https://etherpad.openstack.org/p/puppet-openstack-CI Before working on any task, please make sure to chat with us on IRC or ML, and put your name in the etherpad. Also, any new topics are really welcome, so do thoughts suggestions. Thanks, Thanks for pointing this out, I plan to help with the AIO module. --- Paul Belanger __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Infra] Meeting Tuesday July 14th at 19:00 UTC
Hi everyone, The OpenStack Infrastructure (Infra) team is having our next weekly meeting on Tuesday July 14th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is welcome to to add agenda items) Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend. In case you missed it or would like a refresher, the meeting minutes and full log from our last meeting are available here: Minutes: http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-07-07-19.02.html Minutes (text): http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-07-07-19.02.txt Log: http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-07-07-19.02.log.html -- Elizabeth Krumbach Joseph || Lyz || pleia2 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance] The sorry state of our spec process
On 7/3/15, 05:35, Kuvaja, Erno kuv...@hp.com wrote: First of all, Thanks Flavio for bring this open to the daylight! I agree. More of these discussions need to happen on the mailing list. I have been really frustrated about the Glance spec process since the beginning and as glance core tried to work around the limitations the best I can. I'm not sure if the process is similar way broken on the other projects, but I think after piloting the process in Glance for couple of cycles we should take some action on it. Few comments inline as that way they are easier to scope. -Original Message- From: Flavio Percoco [mailto:fla...@redhat.com] Sent: Wednesday, July 01, 2015 2:49 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [glance] The sorry state of our spec process Greetings, We're 1 week through L-2 (or is it 2?, I can't do time) and we, the glance project, haven't even merged a single spec. Regardless of the reasons behind this situation and the fact that we've been indeed taking steps to improve this situation, I think we should put this issue to an end. This is really sad state to be in. We haven't approved a single spec by the time other projects are already freezing their spec repos for L. I agree we should also have at least a handful of specs already merged along with some of the implementation patches for them. That said, projects that are already freezing their spec repos tend to see many more proposals for us. There are many issues we've faced in Glance: 1. The glance-drivers team is too small [0] 2. Many specs have been held back waiting for code [1] 3. Huge expectations from the spec and very low review rate (even from other members of the glance team). This issue was discussed while ago and was postponed to clarify the Glance Spec process. After that this is first initiative to bring the issue back to table and I'd like to hear if that process defining work is still blocking the expansion to share the workload. If so, could we please get the proposal of that workload or at least the parts of it that needs to be ironed out open in public so we can move that forward as community? So I think I agree with the movement other projects have been taking of accepting a spec before the code is completed and reviewed and then moving it to a list of completed specs once the code has been reviewed, merged, etc. There was a recent discussion on this m-l[2] about the spec process in Nova and while I don't agree with everything that was said there, I do think it highlights important problems that we're facing in glance as well. Therefore, I'd like to propose the following: 1. Expand our drivers team. I thik people in the glance community are getting annoyed of reading this requests from me and The Mythical Man-Month would agree with them. However, it's really sad that some of our oldest (in terms of tenure) contributors that have shown interest in joining the team haven't been added yet. I proposed to bring all cores to the drivers team already and I still think that's a good thing. Assuming that's something we don't want, then I'd like us to find 2 or 3 people willing to volunteer for this task. If this still cannot happen I'd like to get full commitment from our current drivers to dedicate the time and effort for speedy workflow on our specs or step down and trash the whole spec process. So the trick with this is the following: 1. For the drivers team we need people who know glance well as both a product and a codebase and have a clear idea of how both need to move forward. 2. For the drivers team we need people who can also see the architectural implications of specs in review. (other things I'm probably forgetting). It's hard to pick two or three people to just join the team in that case. 2. Lets try to get things into the backlog instead of expecting them to be perfectly shaped and targeted for this release. Lets let people start from a base, generally agreed, idea so that code can be written and reviews on the actual feature can be made. Once the feature is implemented, we can move the spec to the release directory. I believe this was also proposed in Nikola's thread[2]. I'm huge supporter of this. Specs being part of our normal review workflow makes changing them as needed easy and trackable. Why in earth we need to have perfect plan and implementation for that plan before we're willing to indicate approval for the initial idea? 3. Not all specs need to have 3-month-long discussions to be approved. I'm not suggesting to just merge specs that are in poor state but we can't always ask for code to understand whether a spec makes sense or not. Unfortunately, we're already in L-2 and I believe it'll be really hard for some of those features to land in Liberty, which is also sad and quite a waste of time. How long we will have people trying to improve the project if any given proposed functionality takes
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
Excerpts from Matt Riedemann's message of 2015-07-13 08:52:37 -0500: On 7/13/2015 6:57 AM, Jeremy Stanley wrote: On 2015-07-13 10:08:16 +0200 (+0200), Ihar Hrachyshka wrote: clients and oslo libraries still maintain their py26 for a reason: decision to drop py26 was for server projects only. Yes, that decision was made at a time when our server projects had stable branches, but our clients and shared libraries did not. My recollection is that server projects only was a proxy for only projects with stable branches. Now that we have stable branches of, say, python-novaclient where we can backport juno-relevant security fixes, people on 2.6-only platforms who want to install and run python-novaclient from PyPI can use the stable/juno version (though I'll admit that finding which version works with 2.6 may be a tricky proposition for a consumer who is unaware of this situation). Taking python-novaclient as an example, there is still a gating py26 job on that project, so it still works. If/when we drop py26 support for a client, we could tag that commit and then people wanting to use the client on py26 could build a package from before that tag and then lay down whatever other patches they needed. Tempest is already sort of doing some things like this with tagging milestones due to the branchless nature of Tempest, so it seems the same idea could be carried over to the clients in cases like this. We'll want to tag final compatible releases before removing the job, and then after that add a patch removing the trove classifier. The next release after removing the trove classifier should increment the major version number, indicating a drop in expected compatibility. Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] cross-site console web socket proxies no longer work
I noticed in Kilo there’s a validation check in the console web socket proxies to ensure the hostnames from the Origin and Host headers match. This was as a result of CVE-2015-0259 (https://bugs.launchpad.net/nova/+bug/1409142). Effectively it disabled cross-site web socket connections. This is OK for Horizon, but we also run our own custom UI that’s on a different hostname from the console proxy servers. Therefore we need to have the cross-site connections work. I have opened https://bugs.launchpad.net/nova/+bug/1474079 for this. My thought is to add a new nova configuration parameter which would list additional allowed Origin hosts for the proxy servers. And add those to the check at https://github.com/openstack/nova/blob/master/nova/console/websocketproxy.py#L116 I will probably go ahead and implement that for us internally, but interested in opinions on this approach for upstream Nova purposes. I’m happy to do the work, but want to make sure this is generally in line with what the community would accept first. Thanks, Mike __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] python-cinderclient functional tests
On Mon, Jul 13, 2015 at 12:04:05PM -0700, Mike Perez wrote: On 16:28 Jul 10, Ivan Kolodyazhny wrote: Hi Mike, Unfortunately, we don't get a lot of stats [1] because we don't run it often. I've added 'check experimental' comment to latest python-cinderclient review request to get more stats. Review request to make this voting: https://review.openstack.org/#/c/200522/ [1] http://graphite.openstack.org/render/?width=877height=548_salt=1436533755.887from=00%3A00_20150524until=23%3A59_20150710target=stats.zuul.pipeline.experimental.job.check-cinderclient-dsvm-functional.FAILUREtarget=stats.zuul.pipeline.experimental.job.check-cinderclient-dsvm-functional.SUCCESStarget=stats.zuul.pipeline.experimental.openstack.python-cinderclient.total_changestitle=check-cinderclient-dsvm-functional Add an agenda item to the next Cinder meeting. Sure there should be no objections. Just an FYI that these tests used to always be voting until they were removed from tempest. [1][2] Almost every other project that did the same client test migration from tempest just made the new client specific jobs voting from the start so there was no loss in coverage. I'm not entirely sure why cinderclient got stuck as experimental jobs, but it doesn't seem overly contentious to me to just flip the switch. -Matt Treinish [1] https://review.openstack.org/#/c/178757/ [2] http://lists.openstack.org/pipermail/openstack-dev/2015-April/063018.html signature.asc Description: PGP signature __ 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][neutron] question about ceilometer/network/statistics
I'm trying to get my arms around how to develop ceilometer support for networking related data/counters. Seems like there might be a couple of ways to go about this. On the one hand, there are the OpenDaylight and opencontrail contributions in https://github.com/openstack/ceilometer/tree/master/ceilometer/network/statistics There is also the more general notification base class that is discussed somewhat heavily in the ceilometer documentation and in various presentations, and represented by the code here: https://github.com/openstack/ceilometer/blob/master/ceilometer/network/notifications.py There is a third method, polling, that I will ignore as ceilometer seems to disapprove of its use (notifications to the OSLO bus are preferred). Neutron seems to have fairly simple, billing-related counters implemented in NetworkNotificationBase (https://github.com/openstack/ceilometer/blob/master/ceilometer/network/notifications.py, currently around line 39). In https://github.com/openstack/ceilometer/tree/master/ceilometer/network/statistics there are a few python files (e.g., flow.py) that define various counters. The OpenDaylight and opencontrail contributions use very little of these (e.g., nothing from flow.py) - they just publish some basic SNMP-ish data like received and sent packets. So, let's say I have network statistics. How do I approach the problem of integrating them with ceilometer? 1) Do I write my own agent and push whatever I want to OSLO bus, ignoring https://github.com/openstack/ceilometer/blob/master/ceilometer/network/notifications.py and what is in https://github.com/openstack/ceilometer/tree/master/ceilometer/network/statistics ? or 2) Do I use only what is in https://github.com/openstack/ceilometer/tree/master/ceilometer/network/statistics (e.g., the counters in flow.py, port.py, switch.py, table.py) and write a driver? If 2), am I expected to add new python files if something I have to publish to ceilometer is not represented by the counters that are already defined? I believe both opendaylight and opencontrail have ml2 plugins - is this the reason for having ceilometer/network/statistics and driver.py interface? I realize in some sense these are different than say, Cisco nexus in that they are platforms, not switches. Is being a platform with a Neutron plugin the criteria for using driver.py and being located in ceilometer/network/statistics? How does a Nexus plugin write to ceilometer, if it does? Do they have code that they supply customers or partners that supports ceilometer that fits one of these models but is not checked into openstack git repos? Thanks, syd Syd Logan Principal Engineer Network Switching Software Broadcom Corporation Direct: 858-521-5101 Cell: 858-432-8597 __ 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-announce] [release][oslo] oslo.middleware release 2.4.0 (liberty)
We are happy to announce the release of: oslo.middleware 2.4.0: Oslo Middleware library This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.middleware With package available at: https://pypi.python.org/pypi/oslo.middleware For more details, please see the git log history below and: http://launchpad.net/oslo.middleware/+milestone/2.4.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.middleware Changes in oslo.middleware 2.3.0..2.4.0 --- bb6dec2 Fix mocking for 1.1.0 ee8a0cc Updated from global requirements 85baf7d Imported Translations from Transifex 9e2bd3a Updated from global requirements 655de16 Support PasteDeploy e3b7d0e Add tox target to find missing requirements Diffstat (except docs and test files) - .../de/LC_MESSAGES/oslo.middleware-log-error.po| 8 +- .../locale/de/LC_MESSAGES/oslo.middleware.po | 8 +- .../en_GB/LC_MESSAGES/oslo.middleware-log-error.po | 6 +- .../locale/en_GB/LC_MESSAGES/oslo.middleware.po| 6 +- .../fr/LC_MESSAGES/oslo.middleware-log-error.po| 8 +- .../locale/fr/LC_MESSAGES/oslo.middleware.po | 8 +- .../locale/oslo.middleware-log-warning.pot | 14 ++- oslo_middleware/cors.py| 103 - test-requirements.txt | 5 +- tox.ini| 8 ++ 13 files changed, 211 insertions(+), 67 deletions(-) Requirements updates diff --git a/test-requirements.txt b/test-requirements.txt index 962a842..aacc73a 100644 --- a/test-requirements.txt +++ b/test-requirements.txt @@ -5 +5 @@ -fixtures=0.3.14 +fixtures=1.3.1 @@ -7 +7,2 @@ hacking0.11,=0.10.0 -mock=1.0 +mock=1.1;python_version!='2.6' +mock==1.0.1;python_version=='2.6' ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
[openstack-announce] [release][oslo] oslo.config release 1.15.0 (liberty)
We are delighted to announce the release of: oslo.config 1.15.0: Oslo Configuration API This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.config With package available at: https://pypi.python.org/pypi/oslo.config For more details, please see the git log history below and: http://launchpad.net/oslo.config/+milestone/1.15.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.config Changes in oslo.config 1.14.0..1.15.0 - 061ab83 Fix use of mock for 1.1.0 858c5de Updated from global requirements 366ca45 Expose min and max to IntOpt 2576dd3 Don't convert ValueError into NoSuchOptError in ConfigOpts b89f581 Add FAQ entry for why we do not treat config options as API Diffstat (except docs and test files) - oslo_config/cfg.py | 9 +++-- oslo_config/generator.py| 6 test-requirements.txt | 3 +- 8 files changed, 121 insertions(+), 9 deletions(-) Requirements updates diff --git a/test-requirements.txt b/test-requirements.txt index 1a68205..7261313 100644 --- a/test-requirements.txt +++ b/test-requirements.txt @@ -28 +28,2 @@ oslo.i18n=1.5.0 # Apache-2.0 -mock=1.0 +mock=1.1;python_version!='2.6' +mock==1.0.1;python_version=='2.6' ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
[openstack-announce] [release][oslo] taskflow release 1.15.0 (liberty)
We are satisfied to announce the release of: taskflow 1.15.0: Taskflow structured state management library. This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/taskflow With package available at: https://pypi.python.org/pypi/taskflow For more details, please see the git log history below and: http://launchpad.net/taskflow/+milestone/1.15.0 Please report issues through launchpad: http://bugs.launchpad.net/taskflow/ Changes in taskflow 1.14.0..1.15.0 -- 9478226 Provide a deprecated alias for the now removed stop watch class 9633c5b Update all removal_version from being ? to being 2.0 b03d524 Add deprecated and only alias modules for the moved types e34dde2 Updated from global requirements d4b153d Update the version on the old/deprecated logbook module b8d2a5f Fix mock calls 27272a2 Integrate futurist (and **remove** taskflow originating code) 2eb1af3 Allow the 99_bottles.py demo to run in BLATHER mode fcd005f Add more useful `__str__` to redis job c5c2d84 Show job posted and goodbye in 99_bottles.py example 1e3dc09 Rename logbook module - models module 63c6730 Notify on the individual engine steps 2b827e1 Add support for conditional execution 934b2bc Build-out + test a redis backed jobboard 4d0200f Add smarter/better/faster impl. of `ensure_atoms` b7bb295 Add bulk `ensure_atoms` method to storage 9604703 Make it possible to see the queries executed (in BLATHER mode) 40d19c7 Handle conductor ctrl-c more appropriately Diffstat (except docs and test files) - requirements.txt | 3 + setup.cfg | 1 + taskflow/conductors/backends/impl_blocking.py | 34 +- taskflow/conductors/base.py| 13 + taskflow/conductors/single_threaded.py | 2 +- taskflow/engines/action_engine/actions/retry.py| 5 +- taskflow/engines/action_engine/analyzer.py | 160 +++- taskflow/engines/action_engine/engine.py | 5 +- taskflow/engines/action_engine/executor.py | 13 +- taskflow/engines/action_engine/runner.py | 28 +- taskflow/engines/action_engine/runtime.py | 20 + taskflow/engines/base.py | 4 +- taskflow/engines/helpers.py| 2 +- taskflow/engines/worker_based/executor.py | 4 +- taskflow/engines/worker_based/protocol.py | 7 +- taskflow/engines/worker_based/server.py| 4 +- taskflow/engines/worker_based/types.py | 8 +- taskflow/engines/worker_based/worker.py| 4 +- taskflow/examples/99_bottles.py| 113 ++- taskflow/examples/hello_world.py | 9 +- taskflow/examples/parallel_table_multiply.py | 6 +- taskflow/examples/persistence_example.py | 4 +- taskflow/examples/resume_vm_boot.py| 4 +- taskflow/examples/share_engine_thread.py | 4 +- taskflow/examples/switch_graph_flow.py | 75 ++ taskflow/examples/tox_conductor.py | 8 +- taskflow/flow.py | 3 + taskflow/jobs/backends/impl_redis.py | 957 + taskflow/jobs/backends/impl_zookeeper.py | 195 ++--- taskflow/jobs/base.py | 89 +- taskflow/listeners/base.py | 4 +- taskflow/listeners/timing.py | 8 +- taskflow/patterns/graph_flow.py| 18 +- taskflow/persistence/backends/impl_memory.py | 2 +- taskflow/persistence/backends/impl_sqlalchemy.py | 23 +- .../versions/84d6e50_add_task_detail_type.py | 4 +- taskflow/persistence/backends/sqlalchemy/tables.py | 4 +- taskflow/persistence/base.py | 4 +- taskflow/persistence/logbook.py| 889 +-- taskflow/persistence/models.py | 892 +++ taskflow/persistence/path_based.py | 28 +- taskflow/states.py | 5 +- taskflow/storage.py| 144 ++-- taskflow/types/futures.py | 442 +- taskflow/types/latch.py| 4 +- taskflow/types/periodic.py | 199 + taskflow/types/timing.py | 8 +- taskflow/utils/async_utils.py | 9 +- taskflow/utils/misc.py | 53 +- taskflow/utils/persistence_utils.py| 10 +- taskflow/utils/redis_utils.py | 133 +++ taskflow/utils/threading_utils.py | 12 - test-requirements.txt | 6 +- tools/speed_test.py| 4 +- tools/state_graph.py
[openstack-announce] [release][oslo] oslo.messaging release 1.17.0 (liberty)
We are delighted to announce the release of: oslo.messaging 1.17.0: Oslo Messaging API This release is part of the liberty release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.messaging With package available at: https://pypi.python.org/pypi/oslo.messaging For more details, please see the git log history below and: http://launchpad.net/oslo.messaging/+milestone/1.17.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.messaging Changes in oslo.messaging 1.16.0..1.17.0 f04a321 Updated from global requirements 6dda4a7 Updated from global requirements c7b3138 Fix mock use for mock 1.1.0 168f6cc Make heartbeat the default 79b308b Use oslo.log in the zmq receiver 483296e Imported Translations from Transifex c49594a Remove usage of contentmanager for executors ac57114 Verify that version in 'prepare' is valid 286659a Don't reply when we known that client is gone Diffstat (except docs and test files) - .../locale/de/LC_MESSAGES/oslo.messaging.po| 8 +- .../en_GB/LC_MESSAGES/oslo.messaging-log-error.po | 6 +- .../locale/en_GB/LC_MESSAGES/oslo.messaging.po | 4 +- .../es/LC_MESSAGES/oslo.messaging-log-error.po | 6 +- .../locale/es/LC_MESSAGES/oslo.messaging.po| 6 +- .../fr/LC_MESSAGES/oslo.messaging-log-error.po | 8 +- .../locale/fr/LC_MESSAGES/oslo.messaging.po| 6 +- .../ru/LC_MESSAGES/oslo.messaging-log-error.po | 6 +- oslo_messaging/_cmd/zmq_receiver.py| 4 +- oslo_messaging/_drivers/amqp.py| 4 + oslo_messaging/_drivers/amqpdriver.py | 76 +- oslo_messaging/_drivers/impl_rabbit.py | 13 ++- oslo_messaging/_drivers/impl_zmq.py| 4 +- oslo_messaging/_executors/base.py | 18 +--- oslo_messaging/_executors/impl_aioeventlet.py | 4 +- oslo_messaging/_executors/impl_blocking.py | 46 - oslo_messaging/_executors/impl_eventlet.py | 83 ++- oslo_messaging/_executors/impl_pooledexecutor.py | 112 + oslo_messaging/_executors/impl_thread.py | 106 +-- oslo_messaging/_utils.py | 55 ++ oslo_messaging/notify/dispatcher.py| 17 ++-- oslo_messaging/opts.py | 4 +- oslo_messaging/rpc/client.py | 8 ++ oslo_messaging/rpc/dispatcher.py | 6 +- requirements.txt | 3 + test-requirements.txt | 3 +- 37 files changed, 475 insertions(+), 396 deletions(-) Requirements updates diff --git a/requirements.txt b/requirements.txt index 1b29f8a..53dcb5d 100644 --- a/requirements.txt +++ b/requirements.txt @@ -6,0 +7 @@ pbr2.0,=0.11 +futurist=0.1.1 # Apache-2.0 @@ -8,0 +10 @@ oslo.context=0.2.0 # Apache-2.0 +oslo.log=1.2.0 # Apache-2.0 @@ -16,0 +19 @@ six=1.9.0 +cachetools=1.0.0 # MIT License diff --git a/test-requirements.txt b/test-requirements.txt index 66359de..2d6a0c9 100644 --- a/test-requirements.txt +++ b/test-requirements.txt @@ -10 +10,2 @@ fixtures=1.3.1 -mock=1.0 +mock=1.1;python_version!='2.6' +mock==1.0.1;python_version=='2.6' ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
[openstack-dev] [puppet] new etherpad to track Puppet OpenStack CI work
It comes up some people are interested to help with Puppet OpenStack CI work, so here is an etherpad: https://etherpad.openstack.org/p/puppet-openstack-CI Before working on any task, please make sure to chat with us on IRC or ML, and put your name in the etherpad. Also, any new topics are really welcome, so do thoughts suggestions. Thanks, -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ 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] Liberty SFE Request - Dynamic Policies
++! Per my understanding, the work, and therefore the risks, are fairly compartmentalized. The upside is this will pave the way for a much richer authorization management system. Guang From: Adam Young [mailto:ayo...@redhat.com] Sent: Monday, July 13, 2015 10:15 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [keystone] Liberty SFE Request - Dynamic Policies On 07/03/2015 08:36 AM, Samuel de Medeiros Queiroz wrote: Hi Thierry, Thanks for clarifying. A Spec Freeze Exception is what I was supposed to ask for. Rectifying: On behalf of the team working on the Dynamic Policies subject, I would like to ask for a *Spec Freeze Exception* in Liberty for it. This one is an important lead in to a lot of other work. Getting just this in to Liberty allows us to focus the remainder of the work on Dynamic policy inside Keystone. Please approve. Thanks, Samuel de Medeiros Queiroz Thierry Carrez wrote: samuel wrote: [...] On behalf of the team working on the Dynamic Policies subject, I would like to ask for a Feature Freeze Exception in Liberty for it. Liberty Feature Freeze is on September 3rd, so I doubt you need a feature freeze exception at this time. I suspect that would be a spec freeze exception or some other Keystone-specific freeze exception ? https://wiki.openstack.org/wiki/FeatureFreeze __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribemailto: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-Infra] git checkout $ZUUL_NEWREV error reference is not a tree
Sorry for the delayed reply. well this reference is present on the zuul git repository side. when running publish-doc job. zuul is not fetching all the references from the zuul git repository present on CI vm into the workspace/examp_publish-doc on the Jenkins-slave vm. used gerrit-git-prep.sh and example-publis-doc.yaml #!/bin/bash -e GERRIT_SITE=$1 GIT_ORIGIN=$2 if [ -z $GERRIT_SITE ]; then echo The gerrit site name (eg 'https://review.openstack.org') must be the first argument. exit 1 fi if [ -z $ZUUL_URL ]; then echo The ZUUL_URL must be provided. exit 1 fi if [ -z $ZUUL_REF ]; then if [ -n $BRANCH ]; then echo No ZUUL_REF so using requested branch $BRANCH from origin. ZUUL_REF=$BRANCH # use the origin since zuul mergers have outdated branches ZUUL_URL=$GIT_ORIGIN else echo Provide either ZUUL_REF or BRANCH in the calling enviromnent. exit 1 fi fi if [ ! -z $ZUUL_CHANGE ]; then echo Triggered by: $GERRIT_SITE/$ZUUL_CHANGE fi set -x if [[ ! -e .git ]]; then ls -a rm -fr .[^.]* * if [ -d /opt/git/$ZUUL_PROJECT/.git ]; then git clone file:///opt/git/$ZUUL_PROJECT . else git clone $GIT_ORIGIN/$ZUUL_PROJECT . fi fi git remote set-url origin $GIT_ORIGIN/$ZUUL_PROJECT # attempt to work around bugs 925790 and 1229352 if ! git remote update; then echo The remote update failed, so garbage collecting before trying again. git gc git remote update fi git reset --hard if ! git clean -x -f -d -q ; then sleep 1 git clean -x -f -d -q fi if echo $ZUUL_REF | grep -q ^refs/tags/; then git fetch --tags $ZUUL_URL/$ZUUL_PROJECT git checkout $ZUUL_REF git reset --hard $ZUUL_REF elif [ -z $ZUUL_NEWREV ]; then git fetch $ZUUL_URL/$ZUUL_PROJECT $ZUUL_REF git checkout FETCH_HEAD git reset --hard FETCH_HEAD else git checkout $ZUUL_NEWREV git reset --hard $ZUUL_NEWREV fi if ! git clean -x -f -d -q ; then sleep 1 git clean -x -f -d -q fi if [ -f .gitmodules ]; then git submodule init git submodule sync git submodule update --init fi = - job: name: example-publish-doc project-type: freestyle defaults: global description: 'Do not edit this job through the web!' disabled: false display-name: 'example-publish-doc' concurrent: true quiet-period: 5 block-downstream: false block-upstream: false retry-count: 3 node: slave1 logrotate: daysToKeep: 3 numToKeep: 20 artifactDaysToKeep: -1 artifactNumToKeep: -1 properties: - inject: keep-build-variables: true keep-system-variables: true builders: - shell: | #!/bin/bash -xe env /home/corvit/slave_scripts/gerrit-git-prep.sh https://ci.corvit.lab/gerrit ci.corvit.lab:/git /home/corvit/slave_scripts/run-doc.sh cd doc; make latexpdf cd .. /usr/bin/ssh ci.corvit.lab 'sudo rm -rf /home/corvit/doc/example /var/www/html/example' /usr/bin/ssh ci.corvit.lab 'mkdir -p /home/corvit/doc/example' /usr/bin/scp -r doc/build ci.corvit.lab:/home/corvit/doc/example /usr/bin/ssh ci.corvit.lab 'mv /home/corvit/doc/example/build/html /home/corvit/doc/example/build/example' /usr/bin/ssh ci.corvit.lab 'mv /home/corvit/doc/example/build/latex /home/corvit/doc/example/build/example/' /usr/bin/ssh ci.corvit.lab 'sudo mv /home/corvit/doc/example/build/example /var/www/html/' /bin/echo 'Documentation at https://ci.corvit.lab/example/' /bin/echo 'API documentation at https://ci.corvit.lab/example/apidoc.html' /bin/echo 'PDF documentation at https://ci.corvit.lab/example/latex/' Best Regards, Fayyaz Ur Rehman, Corvit Technologies 14-D/1, Ghalib Road, Gulberg III, Lahore, Pakistan. UAN: +92-42-111-CORVIT Tel: +92-42-5717271-2(Ext: 129) Cell: +92-321-4184438 On Tue, Jul 7, 2015 at 2:03 AM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-07-06 10:48:24 +0500 (+0500), Fayyaz rehman wrote: [...] + git checkout 5bc04e0127315bc0107cac27ce00424da965b685 fatal: reference is not a tree: 5bc04e0127315bc0107cac27ce00424da965b685 Build step 'Execute shell' marked build as failure If somebody has any idea why i am facing this error. Please eloborate That's the error git gives you when you try to checkout a nonexistent reference. Are you sure that ref is relevant to the repository in question? -- Jeremy Stanley ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [Openstack] FWaaS and the conntrack table
Hi Peter, What you think about opening a new bug ticket on the project's launchpad, and/or talking with the developers on IRC? Cheers, Marton Kiss On Mon, Jul 13, 2015 at 10:55 AM Erdősi Péter f...@niif.hu wrote: Hi, I've faced a problem with FWaaS plugin in Neutron (Juno). The firewall works, but when I delete a rule from the policy, the connection will still works because of conntrack... (I tried with ping, and ssh) It's okay, if the connection will kept alive, if it's really alive, (an active SSH for example) but if I delete the ICMP rule, and stop pinging, and restart pinging, the ping will still works... If I go to my neutron server, and do a conntrack -F command on my relevant qrouter, the firewall starts working based on the valid rules... Are there any way, to configure the conntrack cleanup when FWaaS configuration modified by user? If not, can somebody help me, where to make changes on code, to run that command in the proper namespace after the iptables rule-generation? Regards, Peter ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Neutron notifiers error on instance delete
On 7/13/2015 6:11 AM, Chris wrote: Hello, When deleting a instance by the openstack API (DELETE {tenant_id} /servers/{server_id}) we see the following error on the neutron server, the instance isn’t deleted and change to error status: 2015-07-06 13:00:31.084 45873 ERROR neutron.notifiers.nova [req-7cf6c8a7-15a2-4c7e-8a84-97e173697ab0 None] Failed to notify nova on events: [{'status': 'completed', 'tag': u'267d2fc6-8ccb-4e6a-b88b-9caa3f09ba83', 'name': 'network-vif-unplugged', 'server_uuid': u'1eb1b855-e8fd-4df0-840e-d5fae0b69dda'}] 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova Traceback (most recent call last): 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/neutron/notifiers/nova.py, line 187, in send_events 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova batched_events) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/novaclient/v1_1/contrib/server_external_events.py, line 39, in create 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova return_raw=True) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/novaclient/base.py, line 152, in _create 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova _resp, body = self.api.client.post(url, body=body) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/novaclient/client.py, line 312, in post 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova return self._cs_request(url, 'POST', **kwargs) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/novaclient/client.py, line 298, in _cs_request 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova method, **kwargs) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/novaclient/client.py, line 268, in _time_request 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova resp, body = self.request(url, method, **kwargs) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File /usr/lib/python2.6/site-packages/novaclient/client.py, line 262, in request 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova raise exceptions.from_response(resp, body, url, method) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova NotFound: No instances found for any event (HTTP 404) (Request-ID: req-63a9ba3f-f1d3-4c5f-ae94-e6a7b4e6bb15) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova 2015-07-06 13:00:31.130 45873 INFO neutron.wsgi [-] (45873) accepted ('10.121.36.25', 49882) Any help appreciated! Cheers, Chris ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack What version of nova and neutron are you running and are there errors in the nova-compute logs that the instance was running on? -- Thanks, Matt Riedemann ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] FWaaS and the conntrack table
What about this: https://bugs.launchpad.net/neutron/+bug/1334926 - ? On 13 July 2015 at 14:03, Marton Kiss marton.k...@gmail.com wrote: Hi Peter, What you think about opening a new bug ticket on the project's launchpad, and/or talking with the developers on IRC? Cheers, Marton Kiss On Mon, Jul 13, 2015 at 10:55 AM Erdősi Péter f...@niif.hu wrote: Hi, I've faced a problem with FWaaS plugin in Neutron (Juno). The firewall works, but when I delete a rule from the policy, the connection will still works because of conntrack... (I tried with ping, and ssh) It's okay, if the connection will kept alive, if it's really alive, (an active SSH for example) but if I delete the ICMP rule, and stop pinging, and restart pinging, the ping will still works... If I go to my neutron server, and do a conntrack -F command on my relevant qrouter, the firewall starts working based on the valid rules... Are there any way, to configure the conntrack cleanup when FWaaS configuration modified by user? If not, can somebody help me, where to make changes on code, to run that command in the proper namespace after the iptables rule-generation? Regards, Peter ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[openstack-dev] [keystone] No IRC Meeting Tuesday July 14
July 14 IRC Meeting is cancelled due to proximity to the Keystone MidCycle (Wed, Thurs, and Fri) of this week. Meetings will resume normal schedule as of July 21. See everyone either at the MidCycle or at the next IRC meeting. __ 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] [Magnum] Magnum Quick-Start: Need clarification on Kubernetes/Redis example
Does anyone have recent experience getting the Kubernetes/Redis example to work in the Magnum developer Quick-Start guide?: https://github.com/openstack/magnum/blob/master/doc/source/dev/dev-quickstart.rst#exercising-the-services-using-devstack I can get everything in the Kubernetes/Redis example to work except for the last step. Here's what the quick-start guide says for this step: Now log into one of the other container hosts and access a redis slave from there: ssh minion@$(nova list | grep 10.0.0.4 | awk '{print $13}') REDIS_ID=$(docker ps | grep redis:v1 | grep k8s_redis | tail -n +2 | awk '{print $1}') docker exec -i -t $REDIS_ID redis-cli 127.0.0.1:6379 get replication:test true ^D exit There are four redis instances, one master and three slaves, running across the bay, replicating data between one another. What I'm seeing is a bit different: (1)I have to use 'sudo docker' instead of 'docker'. (No big deal.) (2)I see one master redis instance on one minion and one slave redis instance on a second minion (each has its own associated sentinel container as expected). (3)The redis-cli command times out with Could not connect to Redis at 127.0.0.1:6379: Connection refused. HOWEVER, if I add a host IP and port for the redis master minion (-h 10.100.84.2 -p 6379), the example works. Here is the failing case, without the host/port arguments: [minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$ REDIS_ID=$(sudo docker ps | grep redis:v1 | grep k8s_redis | awk '{print $1}') [minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$ sudo docker exec -i -t $REDIS_ID redis-cli Could not connect to Redis at 127.0.0.1:6379: Connection refused not connected [minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$ And here is the working case, using -h 10.100.84.2 -p 6379: [minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$ REDIS_ID=$(sudo docker ps | grep redis:v1 | grep k8s_redis | awk '{print $1}') [minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$ sudo docker exec -i -t $REDIS_ID redis-cli -h 10.100.84.2 -p 6379 10.100.84.2:6379 get replication:test true 10.100.84.2:6379 Note that I determined the '10.100.84.2' address for the redis master by running the following on the master minion: [minion@k8-4gmqfvntvm-1-6pnrx2hnxa3d-kube-minion-bh6nynhayhfy ~]$ sudo docker exec -i -t $REDIS_ID ip addr show dev eth0 5: eth0: BROADCAST,UP,LOWER_UP mtu 1472 qdisc noqueue state UP link/ether 02:42:0a:64:54:02 brd ff:ff:ff:ff:ff:ff inet 10.100.84.2/24 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::42:aff:fe64:5402/64 scope link valid_lft forever preferred_lft forever [minion@k8-4gmqfvntvm-1-6pnrx2hnxa3d-kube-minion-bh6nynhayhfy ~]$ So I'm looking for confirmation as to whether or not using the -h 10.100.84.2 -p 6379 arguments is the right way to test this configuration? Is this a successful test? Thanks, Dane __ 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] [Openstack-operators] [openstack-dev] Rescinding the M name decision
On Jul 10, 2015, at 4:19 AM, Thierry Carrez thie...@openstack.org wrote: I think growing up is accepting the pain that comes with picking a good name, rather than sidestepping the issue. I’ve heard the phrase that there are only two hard problems in computer science, and naming is one of them. Just because it is hard is not a reason to avoid doing it. Sometimes the fact that it is hard is the biggest reason why we should do it, and make sure we do it right. We have a naming scheme, based on letters and the location. IMO, we should stick with that, we just need to go further down the list on due diligence, both from a copyright/trademark/legal perspective as well as cultural and other sensitivities that might not have been obvious from the beginning. YMMV. -- Brad Knowles b...@shub-internet.org LinkedIn Profile: http://tinyurl.com/y8kpxu signature.asc Description: Message signed with OpenPGP using GPGMail ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] REMINDER: July 15 Deadline for OpenStack Summit Tokyo Speaker Submissions
Hi everyone, REMINDER: This Wednesday, July 15 at 11:59pm PDT is the deadline to submit a talk for the upcoming OpenStack Summit taking place in Tokyo, October 27-30. Hurry, and submit a talk now! Submit your speaking session proposals HERE https://www.openstack.org/summit/tokyo-2015/call-for-speakers/! You can find more details, including registration, at openstack.org/summit http://openstack.org/summit. If you have any questions, email sum...@openstack.org mailto:sum...@openstack.org. We look forward to seeing you in Tokyo! Cheers, The OpenStack Summit team ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack