[openstack-dev] [nova] FFE Request: Pass image meta to hard reboot for generating xml
Hi, I have a patch need to be reviewed, which fix the bug https://bugs.launchpad.net/nova/+bug/1206809 and this is the commit: https://review.openstack.org/#/c/39668/ I think this is a serious bug because we may lose some features supporting which enabled by the image properity after hard reboot. The description of this bug is below: Currently the libvirt xml of instance will be generated every time during hard reboot by get_guest_config and to_xml method in libvirt driver, but the image_meta is not passed into the get_guest_config method like spawn(), so some configs related to the image_meta will be lost(compared with the spawn process), we need to get the image metadata and passes it to the to_xml method during hard reboot. 2013-09-09 Wangpan___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] FFE Request: Encrypt Cinder volumes
Russell Bryant wrote: I would be good with the exception for this, assuming that: 1) Those from nova-core that have reviewed the code are still happy with it and would do a final review to get it merged. 2) There is general consensus that the simple config based key manager (single key) does provide some amount of useful security. I believe it does, just want to make sure we're in agreement on it. Obviously we want to improve this in the future. +1 I think this is sufficiently self-contained that the regression risk is extremely limited. It's also nice to have a significant hardening improvement in the Havana featurelist. I would just prefer if it landed ASAP since I would like as much usage around it as we can get, to make sure the previous audits didn't miss an obvious bug/security hole in it. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] FFE exception for https://review.openstack.org/#/c/45126/
Robert Collins wrote: This small patch is needed for the pxe orchestration integration that will (finally!) permit using Neutron DHCP rather than a manual dnsmasq for Nova baremetal (and Ironic). We only found out that this was buggy when integration testing, and this patch came in right at the end of the H3 mass of patches :(. Without it, the DHCP integration is unusual. We could perhaps hardcode the value in H, but that would make it spuriously different to what would be in I. So, I'd like a FFE for this patch, if we can. That looks arguably like a bugfix to me. +1 -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron]All unittest passed but Jenkins failed
currently, i don't know if it is coverage problem or something else. the direct cause is: sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post Sep 9 06:57:23 precise1 sudo: jenkins : 3 incorrect password attempts ; TTY=unknown ; PWD=/home/jenkins/workspace/gate-neutron-python27 ; USER=root ; COMMAND=ovs-vsctl --timeout=2 -- --columns=external_ids,name,ofport find Interface external_ids:iface-id=71d9fa4c-f074-46bd-96af-8c592d37c160 meanwhile, i found that: 2013-09-09 06:42:25.922 | + git fetch http://zuul.openstack.org/p/openstack/neutron refs/zuul/master/Z62b50e610b554304bde4aa2a9ea80193 2013-09-09 06:42:26.747 | From http://zuul.openstack.org/p/openstack/neutron 2013-09-09 06:42:26.747 | * branch refs/zuul/master/Z62b50e610b554304bde4aa2a9ea80193 - FETCH_HEAD 2013-09-09 06:42:26.751 | + git checkout FETCH_HEAD 2013-09-09 06:42:26.954 | Warning: you are leaving 17 commits behind, not connected to 2013-09-09 06:42:26.954 | any of your branches: 2013-09-09 06:42:26.954 | 2013-09-09 06:42:26.954 | 62d0927 Avoid shadowing NeutronException 'message' attribute 2013-09-09 06:42:26.954 | e26639b Merge Replace assertEquals with assertEqual 2013-09-09 06:42:26.954 | 5bae582 Load ML2 mech drivers as listed in ml2_conf.ini 2013-09-09 06:42:26.955 | 902dc88 Replace assertEquals with assertEqual 2013-09-09 06:42:26.955 | ... and 13 more. 2013-09-09 06:42:26.955 | 2013-09-09 06:42:26.955 | If you want to keep them by creating a new branch, this may be a good time 2013-09-09 06:42:26.956 | to do so with: 2013-09-09 06:42:26.956 | 2013-09-09 06:42:26.956 | git branch new_branch_name 62d09275d899237dc34cf50c81e99d50489212ff 2013-09-09 06:42:26.956 | 2013-09-09 06:42:26.962 | HEAD is now at 7cbd0f5... Improve dhcp_agent_scheduler but in my local env: $ git log --pretty=format:%h %s 7cbd0f5 Improve dhcp_agent_scheduler 57ce39f Merge Enclose command args in with_venv.sh 9707c73 Merge Imported Translations from Transifex 45beae8 Merge Fix IF checks on spawned green thread instance f7c55db Imported Translations from Transifex 0f81818 Merge Mock midonetclient in test_midonet_lib fc0e7cd Fix IF checks on spawned green thread instance e82f0eb Prevents 400 NVP errors caused by a None display_name e26639b Merge Replace assertEquals with assertEqual 5bae582 Load ML2 mech drivers as listed in ml2_conf.ini fe92e1e Mock midonetclient in test_midonet_lib 902dc88 Replace assertEquals with assertEqual it seems they are not matched? 62d0927 Avoid shadowing NeutronException 'message' attribute is not in my branch, but i already rebase the latest master branch. can anyone help me? review: https://review.openstack.org/#/c/42457/7 log: http://logs.openstack.org/57/42457/7/check/gate-neutron-python27/453c38fhttp://logs.openstack.org/57/42457/7/check/gate-neutron-python27/453c38f/console.html console: http://logs.openstack.org/57/42457/7/check/gate-neutron-python27/453c38f/console.html : -- blog: zqfan.github.com git: github.com/zqfan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] FFE Request: Pass image meta to hard reboot for generating xml
Wangpan wrote: I have a patch need to be reviewed, which fix the bug https://bugs.launchpad.net/nova/+bug/1206809 and this is the commit: https://review.openstack.org/#/c/39668/ I think this is a serious bug because we may lose some features [...] This looks like a bugfix. There is no need for an exception for bug fixes (actually the feature freeze is in place so that we can concentrate on exercising features and fix bugs, until we produce a first release candidate). Regards, -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova][Baremetal][DB] Core review request: bugfix for 1221620
Hi, There is a patch on review (https://review.openstack.org/#/c/45422/) fixing https://bugs.launchpad.net/tripleo/+bug/1221620 which has importance 'Critical' in Nova and TripleO (long story short: currently Nova Baremetal deployments with more than one baremetal node won't work). It would be really nice to have this patch reviewed by core developers, so we can fix the bug ASAP. Thanks, Roman ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Baremetal][DB] Core review request: bugfix for 1221620
On 09/09/13 11:25, Roman Podolyaka wrote: Hi, There is a patch on review (https://review.openstack.org/#/c/45422/) fixing https://bugs.launchpad.net/tripleo/+bug/1221620 which has importance 'Critical' in Nova and TripleO (long story short: currently Nova Baremetal deployments with more than one baremetal node won't work). It would be really nice to have this patch reviewed by core developers, so we can fix the bug ASAP. Hey - thanks for responding quickly - I commented on the patch and tbh I am starting to be -1 on this due to issues mentioned on the review. I will accept that my take on this is too conservative :) and remove a -1 if needed to get this in, but at this point, I have some doubts weather this is the right approach. Cheers, N. Thanks, Roman ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Baremetal][DB] Core review request: bugfix for 1221620
Hi, I'm ok with both accepting this patch and reverting the commit, which introduced the regression, but it would be really nice to have these DB optimizations in Nova. As for your concern of accepting such optimizations. I don't think, it's a problem of such patches themselves, but rather with the lack of comprehensive tests of complex OpenStack installations in our CI (at the same time I personally believe our CI is the best thing ever happened to OpenStack :), CI team you really rock!). Anyway, TripleO-CI found this regression. Maybe we should consider adding its job to Nova check/gate pipelines? Thanks, Roman On Mon, Sep 9, 2013 at 1:59 PM, Nikola Đipanov ndipa...@redhat.com wrote: On 09/09/13 11:25, Roman Podolyaka wrote: Hi, There is a patch on review (https://review.openstack.org/#/c/45422/) fixing https://bugs.launchpad.net/tripleo/+bug/1221620 which has importance 'Critical' in Nova and TripleO (long story short: currently Nova Baremetal deployments with more than one baremetal node won't work). It would be really nice to have this patch reviewed by core developers, so we can fix the bug ASAP. Hey - thanks for responding quickly - I commented on the patch and tbh I am starting to be -1 on this due to issues mentioned on the review. I will accept that my take on this is too conservative :) and remove a -1 if needed to get this in, but at this point, I have some doubts weather this is the right approach. Cheers, N. Thanks, Roman ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] run_tests in debug mode fails
Hi all
I need to debug a specific test but when I try to run it in debug mode using
the run_tests -d (I need to attach pdb) that command fails but if I run the
script without the -d option that works.
I created a brand-new env so I don't think it's related to my local env.
Anyone is experiencing the same issue?
Should I file a nova bug for that?
Error details:
./run_tests.sh -d
nova.tests.integrated.test_servers.ServersTestV3.test_create_and_rebuild_server
Traceback (most recent call last):
File nova/tests/integrated/test_servers.py, line 43, in setUp
super(ServersTest, self).setUp()
File nova/tests/integrated/integrated_helpers.py, line 87, in setUp
self.consoleauth = self.start_service('consoleauth')
File nova/test.py, line 279, in start_service
svc = self.useFixture(ServiceFixture(name, host, **kwargs))
File
/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/testtools/testcase.py,
line 591, in useFixture
fixture.setUp()
File nova/test.py, line 174, in setUp
self.service = service.Service.create(**self.kwargs)
File nova/service.py, line 245, in create
manager = CONF.get(manager_cls, None)
File /home/ubuntu/nova/.venv/lib/python2.7/_abcoll.py, line 342, in get
return self[key]
File
/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py,
line 1610, in __getitem__
return self.__getattr__(key)
File
/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py,
line 1606, in __getattr__
return self._get(name)
File
/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py,
line 1930, in _get
value = self._substitute(self._do_get(name, group, namespace))
File
/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py,
line 1948, in _do_get
info = self._get_opt_info(name, group)
File
/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py,
line 2029, in _get_opt_info
raise NoSuchOptError(opt_name, group)
NoSuchOptError: no such option: consoleauth_manager
Ran 1 test in 11.296s
FAILED (failures=1)
Thanks
--
Andrea
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Baremetal][DB] Core review request: bugfix for 1221620
We deseperately want TripleO in the gate and are working towards it. However, doing that acceptably fast makes it non-trivial [nested VM's are kindof slow...]. If there was BYOI in RackSpace and in HP's non-Beta regions, and custom networking in both clouds, then we could avoid a layer of nesting and test the different TripleO layers independently (and concurrently) but sadly thats not the case yet, so we're having to work on tuning and the occasional hack. We hope to have at least functional tests for nova-bm in soon, with TripleO as a whole following on subsequently to that. -Rob On 9 September 2013 23:12, Roman Podolyaka rpodoly...@mirantis.com wrote: Hi, I'm ok with both accepting this patch and reverting the commit, which introduced the regression, but it would be really nice to have these DB optimizations in Nova. As for your concern of accepting such optimizations. I don't think, it's a problem of such patches themselves, but rather with the lack of comprehensive tests of complex OpenStack installations in our CI (at the same time I personally believe our CI is the best thing ever happened to OpenStack :), CI team you really rock!). Anyway, TripleO-CI found this regression. Maybe we should consider adding its job to Nova check/gate pipelines? Thanks, Roman On Mon, Sep 9, 2013 at 1:59 PM, Nikola Đipanov ndipa...@redhat.com wrote: On 09/09/13 11:25, Roman Podolyaka wrote: Hi, There is a patch on review (https://review.openstack.org/#/c/45422/) fixing https://bugs.launchpad.net/tripleo/+bug/1221620 which has importance 'Critical' in Nova and TripleO (long story short: currently Nova Baremetal deployments with more than one baremetal node won't work). It would be really nice to have this patch reviewed by core developers, so we can fix the bug ASAP. Hey - thanks for responding quickly - I commented on the patch and tbh I am starting to be -1 on this due to issues mentioned on the review. I will accept that my take on this is too conservative :) and remove a -1 if needed to get this in, but at this point, I have some doubts weather this is the right approach. Cheers, N. Thanks, Roman ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] FFE Request: v3 setting v3 API core
Christopher Yeoh wrote: The following 3 changesets in the queue: https://review.openstack.org/#/c/43274/ https://review.openstack.org/#/c/43278/ https://review.openstack.org/#/c/43280/ make keypairs, scheduler hints and console output part of the V3 core api. This essentially changes just two things: - the v3 API server will refuse to startup if they are not loaded (this is the definition of a feature being part of core given that all of the API is an 'extension' now. - the resource is accessed slightly differently - /v3/keypairs rather than /v3/os-keypairs as an example In terms of risk the change is limited to the V3 API only. And although the V3 API will be experimental in Havana anyway and subject to some change I would like to include this because of the resource name changes and minimise any hassle for people who do start using the V3 API in Havana and then want to use it for Icehouse. It has similar downstream effects on documentation. Agreed, that sounds like a useful pre-release cleanup. No objection from me, especially if this is ready to land. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Baremetal][DB] Core review request: bugfix for 1221620
Robert, Cool! That would be really nice! nova-bm functional tests are the bare minimum we need. Thanks, Roman On Mon, Sep 9, 2013 at 2:27 PM, Robert Collins robe...@robertcollins.netwrote: We deseperately want TripleO in the gate and are working towards it. However, doing that acceptably fast makes it non-trivial [nested VM's are kindof slow...]. If there was BYOI in RackSpace and in HP's non-Beta regions, and custom networking in both clouds, then we could avoid a layer of nesting and test the different TripleO layers independently (and concurrently) but sadly thats not the case yet, so we're having to work on tuning and the occasional hack. We hope to have at least functional tests for nova-bm in soon, with TripleO as a whole following on subsequently to that. -Rob On 9 September 2013 23:12, Roman Podolyaka rpodoly...@mirantis.com wrote: Hi, I'm ok with both accepting this patch and reverting the commit, which introduced the regression, but it would be really nice to have these DB optimizations in Nova. As for your concern of accepting such optimizations. I don't think, it's a problem of such patches themselves, but rather with the lack of comprehensive tests of complex OpenStack installations in our CI (at the same time I personally believe our CI is the best thing ever happened to OpenStack :), CI team you really rock!). Anyway, TripleO-CI found this regression. Maybe we should consider adding its job to Nova check/gate pipelines? Thanks, Roman On Mon, Sep 9, 2013 at 1:59 PM, Nikola Đipanov ndipa...@redhat.com wrote: On 09/09/13 11:25, Roman Podolyaka wrote: Hi, There is a patch on review (https://review.openstack.org/#/c/45422/) fixing https://bugs.launchpad.net/tripleo/+bug/1221620 which has importance 'Critical' in Nova and TripleO (long story short: currently Nova Baremetal deployments with more than one baremetal node won't work). It would be really nice to have this patch reviewed by core developers, so we can fix the bug ASAP. Hey - thanks for responding quickly - I commented on the patch and tbh I am starting to be -1 on this due to issues mentioned on the review. I will accept that my take on this is too conservative :) and remove a -1 if needed to get this in, but at this point, I have some doubts weather this is the right approach. Cheers, N. Thanks, Roman ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Baremetal][DB] Core review request: bugfix for 1221620
On 09/09/13 13:12, Roman Podolyaka wrote: Hi, I'm ok with both accepting this patch and reverting the commit, which introduced the regression, but it would be really nice to have these DB optimizations in Nova. As for your concern of accepting such optimizations. I don't think, it's a problem of such patches themselves, but rather with the lack of comprehensive tests of complex OpenStack installations in our CI (at the same time I personally believe our CI is the best thing ever happened to OpenStack :), CI team you really rock!). More CI is always good - and OpenStack CI is amazing without a doubt. However - I think this is not something that ties in very much with these kind of optimisations. The problem with (most) optimisations is that they optimise for a use case. No matter how at scale you tested this - it is still one data point - and this patch does not come for free (regression risk, technical debt to name only a few). You can mitigate some of the issues with CI - but you can't say for sure that this is not in fact slower for people with different deployments/usage patterns. Now this patch may very well be a net win - but I personally have no way of knowing that - and to me - this is the problem with this whole approach - I see the downsides, but don't see the conclusive evidence of the pros of it (we tried it on a really big (tm) cluster - it must be better is not real data IMHO). I realize that we as a project are approaching the point where performance is a thing we need to care about - but then we need to own it as a project (maybe have a sub-team that works on this exclusively). One shot DB query optimisations in Python code seem like a horrible anti-pattern TBH. I may propose a session on this for the summit. Cheers, N. Anyway, TripleO-CI found this regression. Maybe we should consider adding its job to Nova check/gate pipelines? Thanks, Roman On Mon, Sep 9, 2013 at 1:59 PM, Nikola Đipanov ndipa...@redhat.com mailto:ndipa...@redhat.com wrote: On 09/09/13 11:25, Roman Podolyaka wrote: Hi, There is a patch on review (https://review.openstack.org/#/c/45422/) fixing https://bugs.launchpad.net/tripleo/+bug/1221620 which has importance 'Critical' in Nova and TripleO (long story short: currently Nova Baremetal deployments with more than one baremetal node won't work). It would be really nice to have this patch reviewed by core developers, so we can fix the bug ASAP. Hey - thanks for responding quickly - I commented on the patch and tbh I am starting to be -1 on this due to issues mentioned on the review. I will accept that my take on this is too conservative :) and remove a -1 if needed to get this in, but at this point, I have some doubts weather this is the right approach. Cheers, N. Thanks, Roman ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Baremetal][DB] Core review request: bugfix for 1221620
Nikola, The main problem in this case that we use DB in wrong way. If you need in online request to return 100k rows then you are doing something wrong IMHO. And this fix is better then nothing (and it is the best thing that we could do). Best regards, Boris Pavlovic On Mon, Sep 9, 2013 at 4:10 PM, Nikola Đipanov ndipa...@redhat.com wrote: On 09/09/13 13:12, Roman Podolyaka wrote: Hi, I'm ok with both accepting this patch and reverting the commit, which introduced the regression, but it would be really nice to have these DB optimizations in Nova. As for your concern of accepting such optimizations. I don't think, it's a problem of such patches themselves, but rather with the lack of comprehensive tests of complex OpenStack installations in our CI (at the same time I personally believe our CI is the best thing ever happened to OpenStack :), CI team you really rock!). More CI is always good - and OpenStack CI is amazing without a doubt. However - I think this is not something that ties in very much with these kind of optimisations. The problem with (most) optimisations is that they optimise for a use case. No matter how at scale you tested this - it is still one data point - and this patch does not come for free (regression risk, technical debt to name only a few). You can mitigate some of the issues with CI - but you can't say for sure that this is not in fact slower for people with different deployments/usage patterns. Now this patch may very well be a net win - but I personally have no way of knowing that - and to me - this is the problem with this whole approach - I see the downsides, but don't see the conclusive evidence of the pros of it (we tried it on a really big (tm) cluster - it must be better is not real data IMHO). I realize that we as a project are approaching the point where performance is a thing we need to care about - but then we need to own it as a project (maybe have a sub-team that works on this exclusively). One shot DB query optimisations in Python code seem like a horrible anti-pattern TBH. I may propose a session on this for the summit. Cheers, N. Anyway, TripleO-CI found this regression. Maybe we should consider adding its job to Nova check/gate pipelines? Thanks, Roman On Mon, Sep 9, 2013 at 1:59 PM, Nikola Đipanov ndipa...@redhat.com mailto:ndipa...@redhat.com wrote: On 09/09/13 11:25, Roman Podolyaka wrote: Hi, There is a patch on review ( https://review.openstack.org/#/c/45422/) fixing https://bugs.launchpad.net/tripleo/+bug/1221620 which has importance 'Critical' in Nova and TripleO (long story short: currently Nova Baremetal deployments with more than one baremetal node won't work). It would be really nice to have this patch reviewed by core developers, so we can fix the bug ASAP. Hey - thanks for responding quickly - I commented on the patch and tbh I am starting to be -1 on this due to issues mentioned on the review. I will accept that my take on this is too conservative :) and remove a -1 if needed to get this in, but at this point, I have some doubts weather this is the right approach. Cheers, N. Thanks, Roman ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Baremetal][DB] Core review request: bugfix for 1221620
On 09/09/13 14:17, Boris Pavlovic wrote: Nikola, The main problem in this case that we use DB in wrong way. If you need in online request to return 100k rows then you are doing something wrong IMHO. Agreed! And this fix is better then nothing (and it is the best thing that we could do). I am sensitive to that - this is tricky timing for such an issue, and as I stated on the review - will remove the -1 if there are more people who come up and say they want to keep it. I am just speaking up against this way of introducing optimisations which I think is wrong and should happen only in special cases like this (maybe, let's see :)), and not be something we do as a rule. If we want to be serious about performance - we can't keep on doing this - IMHO. N. Best regards, Boris Pavlovic On Mon, Sep 9, 2013 at 4:10 PM, Nikola Đipanov ndipa...@redhat.com mailto:ndipa...@redhat.com wrote: On 09/09/13 13:12, Roman Podolyaka wrote: Hi, I'm ok with both accepting this patch and reverting the commit, which introduced the regression, but it would be really nice to have these DB optimizations in Nova. As for your concern of accepting such optimizations. I don't think, it's a problem of such patches themselves, but rather with the lack of comprehensive tests of complex OpenStack installations in our CI (at the same time I personally believe our CI is the best thing ever happened to OpenStack :), CI team you really rock!). More CI is always good - and OpenStack CI is amazing without a doubt. However - I think this is not something that ties in very much with these kind of optimisations. The problem with (most) optimisations is that they optimise for a use case. No matter how at scale you tested this - it is still one data point - and this patch does not come for free (regression risk, technical debt to name only a few). You can mitigate some of the issues with CI - but you can't say for sure that this is not in fact slower for people with different deployments/usage patterns. Now this patch may very well be a net win - but I personally have no way of knowing that - and to me - this is the problem with this whole approach - I see the downsides, but don't see the conclusive evidence of the pros of it (we tried it on a really big (tm) cluster - it must be better is not real data IMHO). I realize that we as a project are approaching the point where performance is a thing we need to care about - but then we need to own it as a project (maybe have a sub-team that works on this exclusively). One shot DB query optimisations in Python code seem like a horrible anti-pattern TBH. I may propose a session on this for the summit. Cheers, N. Anyway, TripleO-CI found this regression. Maybe we should consider adding its job to Nova check/gate pipelines? Thanks, Roman On Mon, Sep 9, 2013 at 1:59 PM, Nikola Đipanov ndipa...@redhat.com mailto:ndipa...@redhat.com mailto:ndipa...@redhat.com mailto:ndipa...@redhat.com wrote: On 09/09/13 11:25, Roman Podolyaka wrote: Hi, There is a patch on review (https://review.openstack.org/#/c/45422/) fixing https://bugs.launchpad.net/tripleo/+bug/1221620 which has importance 'Critical' in Nova and TripleO (long story short: currently Nova Baremetal deployments with more than one baremetal node won't work). It would be really nice to have this patch reviewed by core developers, so we can fix the bug ASAP. Hey - thanks for responding quickly - I commented on the patch and tbh I am starting to be -1 on this due to issues mentioned on the review. I will accept that my take on this is too conservative :) and remove a -1 if needed to get this in, but at this point, I have some doubts weather this is the right approach. Cheers, N. Thanks, Roman ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org
[openstack-dev] [glance] FFE Request: Add swift_store_ssl_compression param
This change: https://review.openstack.org/#/c/32919/ is the final piece of a puzzle that allows a (potentially significant) performance improvement for image uploads (snapshots)/downloads when using ssl. Its the last change required for the following paths: (nova/cinder) - (glance client) - (glance) - (swift client) - (swift) Without this patch swift will be a bottleneck running at ~17 MB/s while the other parts can potentially reach ~100 MB/s. Risk: Currently the patch sets compression to be disabled by default (giving better performance), but the old behaviour can be reverted by setting the relevant config parameter. (We could even potentially consider defaulting to the old behaviour.) The patch was originally uploaded on Jun 13. -Stuart ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] FFE exception for https://review.openstack.org/#/c/45126/
On 09/09/2013 05:01 AM, Thierry Carrez wrote: Robert Collins wrote: This small patch is needed for the pxe orchestration integration that will (finally!) permit using Neutron DHCP rather than a manual dnsmasq for Nova baremetal (and Ironic). We only found out that this was buggy when integration testing, and this patch came in right at the end of the H3 mass of patches :(. Without it, the DHCP integration is unusual. We could perhaps hardcode the value in H, but that would make it spuriously different to what would be in I. So, I'd like a FFE for this patch, if we can. That looks arguably like a bugfix to me. +1 ACK on the FFE. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] [TROVE] database instance creation
Trove allows you to deploy a single vm with 1 server instance of whichever service supported. So for example, if you were to deploy a mysql instance, you would have 1 vm with 1 mysql instance running on it. You can put as many databases on that one server instance as you would like with as many database users as you would like. On Mon, Sep 9, 2013 at 9:21 AM, Giuseppe Galeota giuseppegale...@gmail.comwrote: Dear all, reading the TROVE's Dochttp://docs.openstack.org/developer/trove/dev/design.htmlI see that Trove is designed to support a single-tenant database within a Nova instance. What does means this? Does it mean that Trove creates a single VM instance in which a single database instance is created? Does it mean that Trove creates a single VM instance in which a more database instances of a single tenant are created ? Thank you, Giuseppe ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] FFE Request: v3 setting v3 API core
On 09/09/2013 07:38 AM, Thierry Carrez wrote: Christopher Yeoh wrote: The following 3 changesets in the queue: https://review.openstack.org/#/c/43274/ https://review.openstack.org/#/c/43278/ https://review.openstack.org/#/c/43280/ make keypairs, scheduler hints and console output part of the V3 core api. This essentially changes just two things: - the v3 API server will refuse to startup if they are not loaded (this is the definition of a feature being part of core given that all of the API is an 'extension' now. - the resource is accessed slightly differently - /v3/keypairs rather than /v3/os-keypairs as an example In terms of risk the change is limited to the V3 API only. And although the V3 API will be experimental in Havana anyway and subject to some change I would like to include this because of the resource name changes and minimise any hassle for people who do start using the V3 API in Havana and then want to use it for Icehouse. It has similar downstream effects on documentation. Agreed, that sounds like a useful pre-release cleanup. No objection from me, especially if this is ready to land. Ok, it's fine with me too, but hopefully it's the last set of v3 API cleanups for havana. We're going to have to get more strict on these sorts of things, soon. We really need to shift focus to bug fixes. Even things like this that are ready come at a cost since it requires reviewer bandwidth. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Needs approval again after rebase
On 09/06/2013 07:04 PM, Yingjun Li wrote: Hi, The patch https://review.openstack.org/43583 was approved but failed to get merged. Could any core reviewer take a look at this after rebase ? Got it. Thanks, -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] [TROVE] database instance creation
Dear all, reading the TROVE's Dochttp://docs.openstack.org/developer/trove/dev/design.html I see that The trove-taskmanager service does the heavy lifting as far as provisioning instances, managing the lifecycle of instances, and performing operations on the *Database instance*. So, once an instance was created, how does an application deployed in the cloud platform (IaaS or PaaS level) perform CRUD operation on that database instance? Maybe, does the trove-taskmanager release an endpoint on which create a DBMS connection? Giuseppe 2013/9/9 Daniel Salinas imsplit...@gmail.com Trove allows you to deploy a single vm with 1 server instance of whichever service supported. So for example, if you were to deploy a mysql instance, you would have 1 vm with 1 mysql instance running on it. You can put as many databases on that one server instance as you would like with as many database users as you would like. On Mon, Sep 9, 2013 at 9:21 AM, Giuseppe Galeota giuseppegale...@gmail.com wrote: Dear all, reading the TROVE's Dochttp://docs.openstack.org/developer/trove/dev/design.htmlI see that Trove is designed to support a single-tenant database within a Nova instance. What does means this? Does it mean that Trove creates a single VM instance in which a single database instance is created? Does it mean that Trove creates a single VM instance in which a more database instances of a single tenant are created ? Thank you, Giuseppe ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] [TROVE] database instance creation
So, I think that Trove is designed to support a *single-tenant *database within a Nova instance is a misleading definition. What do you think? Giuseppe 2013/9/9 Daniel Salinas imsplit...@gmail.com Trove allows you to deploy a single vm with 1 server instance of whichever service supported. So for example, if you were to deploy a mysql instance, you would have 1 vm with 1 mysql instance running on it. You can put as many databases on that one server instance as you would like with as many database users as you would like. On Mon, Sep 9, 2013 at 9:21 AM, Giuseppe Galeota giuseppegale...@gmail.com wrote: Dear all, reading the TROVE's Dochttp://docs.openstack.org/developer/trove/dev/design.htmlI see that Trove is designed to support a single-tenant database within a Nova instance. What does means this? Does it mean that Trove creates a single VM instance in which a single database instance is created? Does it mean that Trove creates a single VM instance in which a more database instances of a single tenant are created ? Thank you, Giuseppe ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [marconi] Agenda for Today's Meeting @ 1600 UTC
The Marconi project team holds a weekly meeting in #openstack-meeting-alt on Mondays, 1600 UTC. The next meeting is today, September 9th. Everyone is welcome. However, please take a minute to review the wiki before attending for the first time: http://wiki.openstack.org/marconi ## Agenda (60 mins): ## * Review actions from last time * SQL Backend * Commit tsung configs in Marconi's tree (https://github.com/rackerlabs/csi-marconi) * Bugs * Performance * Scaling * Triage blueprints (H3) * Open discussion (time permitting) ## Coming soon... ## * Audit and freeze HTTP v1 API See also: http://wiki.openstack.org/Meetings/Marconi Cheers, Kurt (kgriffs) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Tuskar] Meeting agenda for Tue 10th September at 19:00 UTC
The Tuskar team holds a meeting in #openstack-meeting-alt, see https://wiki.openstack.org/wiki/Meetings/Tuskar The next meeting is on Tuesday 10th September at 19:00 UTC. Current topics for discussion: * Documentation * Simplify development setup * Tests * Releases Milestones * Open discussion If you have any other topics to discuss, please add them to the wiki. Thanks, shadower ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Code review (Jenkins-job-builder / sbt-plugin)
Hi, Could someone review/approve this (Added SBT builder supporthttps://review.openstack.org/#/c/44685/), thanks! https://review.openstack.org/#/c/44685/ /Peter ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance] FFE Request: Add swift_store_ssl_compression param
stuart.mcla...@hp.com wrote: This change: https://review.openstack.org/#/c/32919/ is the final piece of a puzzle that allows a (potentially significant) performance improvement for image uploads (snapshots)/downloads when using ssl. I guess that's why I like puzzles being targeted to the second milestone in the cycle... deferring those is painful. Without this patch swift will be a bottleneck running at ~17 MB/s while the other parts can potentially reach ~100 MB/s. Risk: Currently the patch sets compression to be disabled by default (giving better performance), but the old behaviour can be reverted by setting the relevant config parameter. (We could even potentially consider defaulting to the old behaviour.) At this stage of the cycle, I would definitely consider defaulting to the old behavior for Havana, and then this exception would be a no-brainer. With the proposed default, I have to ask how much mileage the SSL without compression swift mode has seen, and the risk is substantially higher. The patch was originally uploaded on Jun 13. Yes, but it was WIP-ed for two months waiting for the necessary support to land in Swift... -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [QA]Tempest CLI Compute-Manage
Best Regards / Saludos! Castulo J. Martinez ISTQB Test Manager QA Engineer | Q1st team @GDC Intel | Security Engineering and Cloud Integration (SECI) Office: +52.33.2282.4083 | iNet: 8286-4083 Before printing consider your Environmental Responsibility! -Original Message- From: Sean Dague [mailto:sda...@gmail.com] On Behalf Of Sean Dague Sent: Monday, September 09, 2013 10:43 AM To: Martinez, Castulo Subject: Re: Tempest CLI Compute-Manage Please post to the openstack-dev list with the [QA] tag On 09/09/2013 11:23 AM, Martinez, Castulo wrote: Hi Sean, I was looking at the Tempest tests and I have a doubt regarding the CLI compute-manage tests. I saw you are one of the main contributors of these, I hope you are the right person to ask you this, if not, I’d appreciate if you could point me to the right direction. When I run the test_compute_manage.py module most of the tests are failing in my environment, however doing some googling I ran into this page from the openStak wiki: https://wiki.openstack.org/wiki/NovaManage In one section of that page I found this comment: The nova-manage isn't properly documented, but it's going away in Folsom, so using this wiki page for quick docs on it. , and since Folsom was released in 2012, I guess the tests failing in Tempest would be a result of that nova-manage component not being in the openStack anymore, at least not functional anyway. But if this is the case, why are these tests still in Tempest? Thanks in advance for your help J Best Regards / Saludos! ** *Castulo J. Martinez* *ISTQB Test Manager* QA Engineer | Q1st team @GDC Intel*|* Security Engineering and Cloud Integration (SECI) *Office:*+52.33.2282.4083 *| iNet:* 8286-4083 PBefore printing consider your *Environmental Responsibility!* -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Infra] Meeting Tuesday September 10th at 19:00 UTC
The OpenStack Infrastructure (Infra) team is hosting our weekly meeting tomorrow, Tuesday September 10th, 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. We're also having our Bug Day tomorrow, starting at 17:00 UTC, notes will be coming together here: https://etherpad.openstack.org/cibugreview-september2013 -- Elizabeth Krumbach Joseph || Lyz || pleia2 http://www.princessleia.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance] FFE Request: Add swift_store_ssl_compression param
I buy an exception here if the configuration defaults to off (no change). Thanks! On Mon, Sep 9, 2013 at 8:29 AM, Thierry Carrez thie...@openstack.orgwrote: stuart.mcla...@hp.com wrote: This change: https://review.openstack.org/#/c/32919/ is the final piece of a puzzle that allows a (potentially significant) performance improvement for image uploads (snapshots)/downloads when using ssl. I guess that's why I like puzzles being targeted to the second milestone in the cycle... deferring those is painful. Without this patch swift will be a bottleneck running at ~17 MB/s while the other parts can potentially reach ~100 MB/s. Risk: Currently the patch sets compression to be disabled by default (giving better performance), but the old behaviour can be reverted by setting the relevant config parameter. (We could even potentially consider defaulting to the old behaviour.) At this stage of the cycle, I would definitely consider defaulting to the old behavior for Havana, and then this exception would be a no-brainer. With the proposed default, I have to ask how much mileage the SSL without compression swift mode has seen, and the risk is substantially higher. The patch was originally uploaded on Jun 13. Yes, but it was WIP-ed for two months waiting for the necessary support to land in Swift... -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [marconi] Summary from today's meeting
Hi Folks, Today we discussed the SQL driver, performance patches, and a few other interesting tidbits. Summary: http://goo.gl/RbeSUa Log: http://goo.gl/UqNSPj Note also that we now have eavesdrop working for #openstack-marconi so you can find our day-to-day chats archived in the usual place: http://eavesdrop.openstack.org/irclogs/ Cheers, Kurt (kgriffs) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Code review (Jenkins-job-builder / sbt-plugin)
I believe we are waiting for Mathieu Gagné re-review before approving. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna-dashboard] version 0.3 - updated UI mockups for EDP workflow
Updated UI mockups for savanna dashboard EDP. https://wiki.openstack.org/wiki/Savanna/UIMockups/JobCreation Regards, Chad ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA]Tempest CLI Compute-Manage
On Mon, Sep 9, 2013 at 10:48 AM, Martinez, Castulo castulo.marti...@intel.com wrote: Best Regards / Saludos! Castulo J. Martinez ISTQB Test Manager QA Engineer | Q1st team @GDC Intel | Security Engineering and Cloud Integration (SECI) Office: +52.33.2282.4083 | iNet: 8286-4083 Before printing consider your Environmental Responsibility! -Original Message- From: Sean Dague [mailto:sda...@gmail.com] On Behalf Of Sean Dague Sent: Monday, September 09, 2013 10:43 AM To: Martinez, Castulo Subject: Re: Tempest CLI Compute-Manage Please post to the openstack-dev list with the [QA] tag On 09/09/2013 11:23 AM, Martinez, Castulo wrote: Hi Sean, I was looking at the Tempest tests and I have a doubt regarding the CLI compute-manage tests. I saw you are one of the main contributors of these, I hope you are the right person to ask you this, if not, I’d appreciate if you could point me to the right direction. When I run the test_compute_manage.py module most of the tests are failing in my environment, however doing some googling I ran into this page from the openStak wiki: https://wiki.openstack.org/wiki/NovaManage In one section of that page I found this comment: The nova-manage isn't properly documented, but it's going away in Folsom, so using this wiki page for quick docs on it. , and since Folsom was released in 2012, I guess the tests failing in Tempest would be a result of that nova-manage component not being in the openStack anymore, at least not functional anyway. But if this is the case, why are these tests still in Tempest? Sadly that wiki page is incorrect, nova-manage is still around. nova-manage doesn't use the REST APIs and must be run locally on a machine with a valid nova.conf file. Thanks in advance for your help J Best Regards / Saludos! ** *Castulo J. Martinez* *ISTQB Test Manager* QA Engineer | Q1st team @GDC Intel*|* Security Engineering and Cloud Integration (SECI) *Office:*+52.33.2282.4083 *| iNet:* 8286-4083 PBefore printing consider your *Environmental Responsibility!* -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] FFE Request: Encrypt Cinder volumes
On 9/9/13 9:25 AM, Russell Bryant rbry...@redhat.com wrote: On 09/09/2013 04:57 AM, Thierry Carrez wrote: Russell Bryant wrote: I would be good with the exception for this, assuming that: 1) Those from nova-core that have reviewed the code are still happy with it and would do a final review to get it merged. 2) There is general consensus that the simple config based key manager (single key) does provide some amount of useful security. I believe it does, just want to make sure we're in agreement on it. Obviously we want to improve this in the future. +1 I think this is sufficiently self-contained that the regression risk is extremely limited. It's also nice to have a significant hardening improvement in the Havana featurelist. I would just prefer if it landed ASAP since I would like as much usage around it as we can get, to make sure the previous audits didn't miss an obvious bug/security hole in it. The response seems positive from everyone so far. I think we should approve this and try to get it merged ASAP (absolutely this week, and hopefully in the first half of the week). ACK on the FFE from me. Me as well for what it's worth. While I understand the concerns around key management, Barbican will have our 1.0 release for Havana and it should be relatively easy to integrate the proposed patches with Barbican at that time. Even so, the current version does offer some security and gives us the ability to have the code tested before we introduce another moving part. Thanks, Jarret Raim ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] summit.openstack.org track label for TripleO - Deployment
Thierry, is it possible to change this to 'Deployment' rather than TripleO in the summit tool? I think it would avoid folk interested in Tuskar failing to find a place to submit their proposals, and as a program we are multi-project - Tomas and I have just discussed this in the tripleo meeting slot and think it would be a good idea. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Scaling of TripleO
On 10 September 2013 08:04, Mike Spreitzer mspre...@us.ibm.com wrote: My vision for TripleO/undercloud and scale in the long term is: - A fully redundant self-healing undercloud - (implies self hosting) ... Robert, what do you mean by self hosting? If a cloud can self-host, why do we need two clouds (under and over)? Running the baremetal scheduler and a regular scheduler is still not pretty; the baremetal scheduler exact-matches on memory etc, vs a subdividing scheduler which looks for 'fits in'. You can work around this by running cells. However, there is a very nice separation of concerns in having your production cloud and your deployment cloud completely disconnected. For instance, a configuration error is much less able to permit a tenant of your production cloud deploying onto baremetal when they shouldn't. Relatedly, being able to spin up multiple overclouds gives you a great dev/CI story: test your overcloud by having a parallel test overcloud sitting on the same undercloud substrate. That said, I think it's feasible to support a single cloud for folk that want it - and initially when we started this I wanted it, I just no longer think that it's actually the ideal configuration :). -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Scaling of TripleO
Robert Collins robe...@robertcollins.net wrote on 09/06/2013 05:31:14 PM: From: Robert Collins robe...@robertcollins.net To: OpenStack Development Mailing List openstack-dev@lists.openstack.org, Date: 09/06/2013 05:36 PM Subject: Re: [openstack-dev] [tripleo] Scaling of TripleO ... My vision for TripleO/undercloud and scale in the long term is: - A fully redundant self-healing undercloud - (implies self hosting) ... Robert, what do you mean by self hosting? If a cloud can self-host, why do we need two clouds (under and over)? Thanks, Mike___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] FFE Request: Encrypt Cinder volumes
On Mon, Sep 9, 2013 at 1:20 PM, Jarret Raim jarret.r...@rackspace.comwrote: On 9/9/13 9:25 AM, Russell Bryant rbry...@redhat.com wrote: On 09/09/2013 04:57 AM, Thierry Carrez wrote: Russell Bryant wrote: I would be good with the exception for this, assuming that: 1) Those from nova-core that have reviewed the code are still happy with it and would do a final review to get it merged. 2) There is general consensus that the simple config based key manager (single key) does provide some amount of useful security. I believe it does, just want to make sure we're in agreement on it. Obviously we want to improve this in the future. +1 I think this is sufficiently self-contained that the regression risk is extremely limited. It's also nice to have a significant hardening improvement in the Havana featurelist. I would just prefer if it landed ASAP since I would like as much usage around it as we can get, to make sure the previous audits didn't miss an obvious bug/security hole in it. The response seems positive from everyone so far. I think we should approve this and try to get it merged ASAP (absolutely this week, and hopefully in the first half of the week). ACK on the FFE from me. Me as well for what it's worth. While I understand the concerns around key management, Barbican will have our 1.0 release for Havana and it should be relatively easy to integrate the proposed patches with Barbican at that time. Even so, the current version does offer some security and gives us the ability to have the code tested before we introduce another moving part. Thanks, Jarret Raim ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Fine on the Cinder side for the related components there. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Bug #1209011
Carl- Thanks for pointing this out. I've fixed the bug status. mark On Sep 9, 2013, at 6:33 PM, Baldwin, Carl (HPCS Neutron) carl.bald...@hp.com wrote: Hi all, This bug was marked as fix released for H-3. However, the fix that was merged was reverted due to gate breakage. The patch was resubmitted as https://review.openstack.org/#/c/42412/ and fixes the gate breakage but this new patch has not been merged. So, the bug state of Yix released is not accurate. This bug needs one of the following two actions: 1) The new patch accepted and bug state changed to Fix Committed. 1) Bug state reverted to In Progress. Thanks, Carl ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] Modify source code for Postgres engine
On Sep 6, 2013, at 8:19 AM, Giuseppe Galeota wrote: Dear all, this is a technical question. I would try to modify the source code of Trove in order to create databases instances using Postgres engine. I think that it is necessary to modify the create method in the InstanceController class. Is it right? What other things should I modify? Hi Giuseppe, When I proposed trove to be a openstack incubated project, i created a postgres work in progress. [1] It may help answer some of your questions. Many things have changed since then ( i think its been 3+ mo now), but it will show you where to start. [1] https://review.openstack.org/#/c/28328/ signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Gate breakage for multi-process API patch.
Hi all, https://review.openstack.org/#/c/37131/ This review has been consistently marked as fail for the last three patch sets. I'm scratching my head over how the failure is related to the patch. Can anyone lend some insight? Is this a known failure that is not caused by my patch or is this failure actually due to my patch? The test breaking is test_008_check_public_network_connectivity. I have run the patch with the new api_workers config option set to 0, 1, 2, and 5 and I've been able to create instances that have full network connectivity to my public network in each case. Thanks, Carl ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Bug #1209011
Hi all, This bug was marked as fix released for H-3. However, the fix that was merged was reverted due to gate breakage. The patch was resubmitted as https://review.openstack.org/#/c/42412/ and fixes the gate breakage but this new patch has not been merged. So, the bug state of Yix released is not accurate. This bug needs one of the following two actions: 1) The new patch accepted and bug state changed to Fix Committed. 1) Bug state reverted to In Progress. Thanks, Carl ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Gate breakage for multi-process API patch.
Carl, if you check the rechecks page - http://status.openstack.org/rechecks/you will see 18 other reviews hitting the same bug reported at https://bugs.launchpad.net/tempest/+bug/1197476. So, in your review for https://review.openstack.org/#/c/37131/, add a comment recheck bug 1197476 which will basically re-run the jenkins tests and update the rechecks page with your review number. See here for more info - https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures -- dims On Mon, Sep 9, 2013 at 6:40 PM, Baldwin, Carl (HPCS Neutron) carl.bald...@hp.com wrote: Hi all, https://review.openstack.org/#/c/37131/ This review has been consistently marked as fail for the last three patch sets. I'm scratching my head over how the failure is related to the patch. Can anyone lend some insight? Is this a known failure that is not caused by my patch or is this failure actually due to my patch? The test breaking is test_008_check_public_network_connectivity. I have run the patch with the new api_workers config option set to 0, 1, 2, and 5 and I've been able to create instances that have full network connectivity to my public network in each case. Thanks, Carl ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Gate breakage for multi-process API patch.
Thank you for that information. I see that rechecks page referenced from the wiki now that you have mentioned it. I have learned something. Carl Sent from my HTC - Reply message - From: Davanum Srinivas dava...@gmail.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] Gate breakage for multi-process API patch. Date: Mon, Sep 9, 2013 5:49 PM Carl, if you check the rechecks page - http://status.openstack.org/rechecks/ you will see 18 other reviews hitting the same bug reported at https://bugs.launchpad.net/tempest/+bug/1197476. So, in your review for https://review.openstack.org/#/c/37131/, add a comment recheck bug 1197476 which will basically re-run the jenkins tests and update the rechecks page with your review number. See here for more info - https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures -- dims On Mon, Sep 9, 2013 at 6:40 PM, Baldwin, Carl (HPCS Neutron) carl.bald...@hp.commailto:carl.bald...@hp.com wrote: Hi all, https://review.openstack.org/#/c/37131/ This review has been consistently marked as fail for the last three patch sets. I'm scratching my head over how the failure is related to the patch. Can anyone lend some insight? Is this a known failure that is not caused by my patch or is this failure actually due to my patch? The test breaking is test_008_check_public_network_connectivity. I have run the patch with the new api_workers config option set to 0, 1, 2, and 5 and I've been able to create instances that have full network connectivity to my public network in each case. Thanks, Carl ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] FFE Request: v3 setting v3 API core
On Tue, Sep 10, 2013 at 12:01 AM, Russell Bryant rbry...@redhat.com wrote: On 09/09/2013 07:38 AM, Thierry Carrez wrote: Christopher Yeoh wrote: The following 3 changesets in the queue: Agreed, that sounds like a useful pre-release cleanup. No objection from me, especially if this is ready to land. Ok, it's fine with me too, but hopefully it's the last set of v3 API cleanups for havana. Thanks Russell. Everything else v3 api related (except for bug fixes/tests) we'll defer to Icehouse. Regards, Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack + PyPy: Status and goals
Hi Alex, That's really cool! I believe, performance is not the only benefit we can get from running OpenStack projects on PyPy. We can also improve the overall correctness of our code (as PyPy behaves differently with non-closed files, etc), just like compiling of your C/C++ app using different compilers can show hidden errors. And what about eventlet? Does it work well on PyPy? (as it is used in Nova, Neutron, etc) Thanks, Roman On Tue, Sep 10, 2013 at 12:28 AM, Alex Gaynor alex.gay...@gmail.com wrote: Hi all, Many of you have probably seen me send review requests in the last few weeks about adding PyPy support to various OpenStack projects. A few people were confused by these, so I wanted to fill everyone in on what I'm up to :) First, for those who aren't familiar with what PyPy is: PyPy is an implementation of the Python language which includes a high performance tracing just-in-time compiler and which is faster than CPython (the reference, and most widely deployed, implementation) on almost all workloads. The current status is: Two major projects work, both Marconi and Swift, Marconi is gating against PyPy already, Swift isn't yet since I needed to fix a few small PyPy bugs and those aren't in a release yet, expect it soon :) In terms of results, I've observed 30% performance improvements on GET workloads for Swift under PyPy vs. CPython (other workloads haven't been benchmarked tet). I believe the Marconi folks have also observed some performance wins, but I'll let them speak to that, I don't have the full details. Many python-clients projects are also working out of the box and gating: including novaclient, swiftclient, marconiclient, ceilometerclient, heatclient, and ironicclient! There's a few outstanding reviews to add PyPy gating for cinderclient, troveclient, and glanceclient. In terms of future direction: I'm going to continue to work on getting more projects running and gating against PyPy. Right now I'm focusing a lot of my attention on improving Swift performance, particularly under PyPy, but also under CPython. I'm hoping some day PyPy will be the default way to deploy OpenStack! If you're interested in getting your project running on PyPy, or looking at performance under it, please let me know, I'm always interested in helping! Thanks, Alex -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
