File - Settings - Python Debugger
Mark Gevent compatible debugging
On Thu, Mar 19, 2015 at 12:06 AM, Daniel Comnea comnea.d...@gmail.com
wrote:
Gal,
while i don't have an answer to your question, can you pls share how you
enabled the Gevent debugging?
Thx,
Dani
On Wed, Mar 18, 2015
Hi all. I have setup kilo designate services with powerdns backend and
mysql innodb storage in a single node.
The services function well at first. However, after inserting 13k A records
via API within 3 domains (5k, 5k, 3k for each), the service stops working.
designate-api returns 500 and many
Hi Mike,
Regarding the GlusterFS CI:
As I am dealing with end to end CI process of GlusterFS, please modify
the contact person to bharat.kobag...@redhat.com.
Because of this I may miss important announcements from you regarding
the CI.
On 03/19/2015 11:11 AM, Mike Perez wrote:
The
Forwarding my reply to the other thread here:
If my memory does not fail me, changes to the API (new resources, new
resource attributes or new operations allowed to resources) have always
been done according to these criteria:
- an opt-in approach: this means we know the expected
Hello Folks,
[tl;dr]
On implicit chains, the Service Chain Instance ownership in GBP is
inconsistent, depending on the actor triggering the chain. Possible
solution is to have all the implicit SCI owned by an admin, or by the
provider of the chain. Any suggestion is welcome.
If my memory does not fail me, changes to the API (new resources, new
resource attributes or new operations allowed to resources) have always
been done according to these criteria:
- an opt-in approach: this means we know the expected behavior of the
plugin as someone has coded the plugin
I OK kook i rigor w assessment of ofiii
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
So others have/will chime in here... one thing I think is kinda missing in
the statement above is the single host, that's actually the whole point
of Ceph and other vendor driven clustered storage technologies out there.
There's a ton to choose from at this point, open source as well as
Just one question regarding this bit:
There are some plans (unfortunately I do not know details, so maybe
someone from OSCI could tell more) to split those repositories
Splitting of repositories doesn't help to solve python packages
conflicts because master node uses a number of openstack
https://review.openstack.org/#/q/status:open+project:stackforge/python-fuelclient+branch:master+topic:bp/re-thinking-fuel-client,n,z
https://review.openstack.org/#/q/status:open+project:stackforge/python-fuelclient+branch:master+topic:bp/re-thinking-fuel-client,n,z
17 бер. 2015 о 18:51 Mike
This is a good workaround to allow the authentication on the IdP but with the
new websso is problematic because
you do not know which mapping to use but you have the Shib-Identity-Provider.
With the new information
the entityIDs are associated with the keystone IdP so it is easy to find the
+1 from me also
On Thu, Mar 19, 2015 at 1:07 PM, Roman Prykhodchenko m...@romcheg.me wrote:
https://review.openstack.org/#/q/status:open+project:stackforge/python-fuelclient+branch:master+topic:bp/re-thinking-fuel-client,n,z
17 бер. 2015 о 18:51 Mike Scherbakov mscherba...@mirantis.com
Hello,
I was trying to raise the cap for Django in[1].
It looks quite simple, current requirements is
Django=1.4.2,1.7
and I simply removed the upper boundary:
Django=1.4.2
with the result, django-nose is not installed any more.
(That's a rest dependency for horizon), it's listed in the same
Hi,
I'm looking at this interesting blueprint
https://blueprints.launchpad.net/heat/+spec/stack-lifecycle-plugpoint and I
hope you can easily clarify some things to me.
I see the following statements related to this BP:
* [in problem description section]: There are at least two primary use
Folks,
I assume you meant: If a requirement that previously was only in Fuel
Requirements is merged to Global Requirements, it should be removed
from *Fuel* Requirements».
Exactly.
I'm not sure it's good idea.
We should stay so close to upstream distro as we can. It should be
very
Hello everyone,
I am using Ceilometer to monitor both physical servers and virtutal machines in
IAAS.
And I found current Ceilometer only support 4 memory oid of SNMP:
_memory_total_oid = 1.3.6.1.4.1.2021.4.5.0
_memory_avail_real_oid = 1.3.6.1.4.1.2021.4.6.0
_memory_total_swap_oid =
Hi Adam,
Disclaimer: i work for a company interested in providing solutions based on
openstack, but this email should not be considered marketing/promotional
Regarding your second question Using Swift as a back-end for Cinder, we
already have a solution for this, a part of which is a Cinder
Roman, all
- OSCI mirror should contain the maximum version of a requirement
that matches its version specification.
I'm not sure it's good idea.
We should stay so close to upstream distro as we can. It should be
very important reason to update package against it's upstream distro
Hi,
It appears that https://review.openstack.org/#/c/158420/ update the base
attributes for the networks. Is there any reason why this was not added as a
separate extension like all others.
I do not think that this is the correct way to go and we should do this as all
other extensions have been
Hi,
This patch has the same addition too -
https://review.openstack.org/#/c/154921/. We should also revert that one.
Thanks
Gary
From: Gary Kotton gkot...@vmware.commailto:gkot...@vmware.com
Reply-To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date:
Hi Joe,
Sorry for the late response.
Here are some latest logs for the Nova CI:
http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20150318_1650/
http://144.76.193.39/ci-artifacts/Check-MLNX-Nova-ML2-Sriov-driver_20150318_1506/
Folks,
Correct me if I am wrong, but isn't it what we have containers on master
node for?
On the master node itself conflicts won’t happen because the components are
run in their containers.
Do you propose to use _separate_ package repository for each docker
container? (It means separate
I guess it would depend on how many docker containers are running on master
node and if we are able to pull off such stunt :).
I am not familiar with the amount of work needed to do sth like that, so
the proposition may be silly. Just let me know if it is.
On Thu, Mar 19, 2015 at 11:51 AM,
Hello,
While on a long oversea flight with Sebastien Han we were talking how he
had implemented ceph-docker with central configuration over etcd. We
quickly came up to the conclusion that if we wanted to have that in Kolla
it would be neat if it was done straight from oslo.config so that would
Hello,
Some time ago I wrote some small tools that make Fuel development easier
and it was suggested to add info about them to the documentation --
here's the review link [1].
Evgenyi Li correctly pointed out that we already have something like
fuel_development already in fuel-web. I think
Congrats, sdake !!
-- pshige
2015-03-18 16:09 GMT+09:00 Daniel Comnea comnea.d...@gmail.com:
Congrats Steve!
On Wed, Mar 18, 2015 at 12:51 AM, Daneyon Hansen (danehans)
daneh...@cisco.com wrote:
Congratulations Steve!
Regards,
Daneyon Hansen
Software Engineer
Email:
This is more in line with my argument that we should not have 100
different end points and mapping rules for a federation of 100 IdPs, but
rather one end point and one mapping for all trusted IdPs. But I still
think that in order to make this design waterproof we need a trusted
attributes policy
Hi,
Changed the subject so that it may draw a little attention.
There were 2 patches approved that kind of break the API (in my humble opinion):
https://review.openstack.org/#/c/154921/ and
https://review.openstack.org/#/c/158420/
In both of these two new fields were added to the base attributes
On Wed, Mar 18, 2015 at 6:59 AM, Serg Melikyan smelik...@mirantis.com
wrote:
Thank you!
On Wed, Mar 18, 2015 at 8:28 AM, Sergey Lukjanov slukja...@mirantis.com
wrote:
The PTL candidacy proposal time frame ended and we have only one
candidate.
So, Serg Melikyan, my congratulations!
Team,
Do we have a ballpark amount for the memory of the devstack machine to
run magnum? I am running devstack as a VM with (4 VCPU/50G-Disk/8G-Mem)
and running magnum on it as per[1].
I am observing the kube-Nodes goes often in SHUTOFF state. If I do
'nova reset-state', the instance goes
Hi Mike,
Regarding the Huawei Volume CI:
As I am dealing with the CI process of Huawei, please modify the contact person
to liuxin...@huawei.commailto:liuxin...@huawei.com, so I won't miss
important announcements from you regarding the CI.
The CI of huawei 18000 ISCSI and huawei 18000 FC
Hello,
I want to initiate a discussion about different backend storage types for
Ceph. Now all types of drives (HDD, SAS, SSD) are treated the same way, so
the performance can vary widely.
It would be good to detect SSD drives and create separate Ceph pool for
them. From the user perspective, it
Hi Mike,
I have seen the patch at https://review.openstack.org/#/c/165990/ saying that
huawei driver will be removed because “the maintainer does not have a CI
reporting to ensure their driver integration is successful”.
But in fact we really have a CI months ago and it is really reporting to
Hi Mike,
* Maybe I have a misunderstandapp:ds:misunderstand of the
warningapp:ds:warning you said that all drivers must have a CI. I have taken
that as if the Dorado and T driver did not have a CI then the Dorado and T
driver will be removed from the community individually.
If I can't
Hi Surojit,
I think 8G of RAM and 80G of disk should be considered the minimum. The
guide will create 3 m1.small VMs (each with 2G of RAM and 20G of disk), and
2 volumes (5G each).
In your case, I am not sure why you get the memory error. Probably, you
could walk-around it by creating a flavor
There are precedents for this. For example, the attributes that currently
exist for IPv6 advertisement are very similar:
- added during the run of a stable Neutron API
- properties added on a Neutron object (MTU and VLAN affect network, but
IPv6 affects subnet - same principle though)
-
+1 -- there is no point for commiting that review with external urls if
those repos are to be created in stackforge.
P.
On 03/19/2015 03:02 PM, Evgeniy L wrote:
Hi folks,
I agree, lets create separate repo with its own cores and remove
fuel_development from fuel-web.
But in this case I'm
+1 for moving fuel_development into separate repo.
On Thu, Mar 19, 2015 at 5:02 PM, Evgeniy L e...@mirantis.com wrote:
Hi folks,
I agree, lets create separate repo with its own cores and remove
fuel_development from fuel-web.
But in this case I'm not sure if we should merge the patch which
Hi folks,
I agree, lets create separate repo with its own cores and remove
fuel_development from fuel-web.
But in this case I'm not sure if we should merge the patch which
has links to non-stackforge repositories, because location is going
to be changed soon.
Also it will be cool to publish it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/19/2015 07:41 AM, stanzgy wrote:
Hi all. I have setup kilo designate services with powerdns backend and mysql
innodb storage in a
single node.
The services function well at first. However, after inserting 13k A
records via API within 3
As I wrote in the review already: I like the idea of merging
those two tools and making a separate repository. After that
we could make they more visible in our documentation and wiki
so they could benefit from being used by broader audience.
Same for vagrant configuration - if it's useful (and
Hi Zhang,
Thank you for reporting the bug. The number of records does not seem too high.
At this point I do not have a suggestion to improve the situation, but I will
investigate this. Could you file a bug report? Relevant log snippets would also
be helpful.
--vinod
From: stanzgy
Corrected [1] is below (link for pxe_ilo patch review):
[1] https://review.openstack.org/#/c/154808/
On Thu, Mar 19, 2015 at 10:24 PM, Devananda van der Veen
devananda@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
This feature [0] enables secure boot mode for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
This feature [0] enables secure boot mode for hardware which supports UEFI.
Ironic added support for UEFI in Juno. This is an incremental improvement,
allowing those users to benefit more from their hardware's security features.
After this
On Thu, Mar 19, 2015 at 3:16 AM, Roman Prykhodchenko m...@romcheg.me wrote:
I'm not sure it's good idea.
We should stay so close to upstream distro as we can. It should be
very important reason to update package against it's upstream distro
The issue is the following: OpenStack’s components
Hi,
Until now all changes to the API’s have been made in separate extensions and
not in the base. These should actually be on the provider networks extension.
First this code is not supported by any of the plugins other than the ML2 (I am
not sure if this break things – it certain broke the unit
Hello everyone,
I have dug into this problem and I realized that this piece of code is working
on a CentOS 6.6 running Openstack stable icehouse installed with RDO.
My guess is that there may be an issue either with the operating system or with
the devstack installation.
If you have any clue,
woops! thanks...
-Devananda
On Thu, Mar 19, 2015 at 10:04 AM, Ramakrishnan G
rameshg87.openst...@gmail.com wrote:
Corrected [1] is below (link for pxe_ilo patch review):
[1] https://review.openstack.org/#/c/154808/
On Thu, Mar 19, 2015 at 10:24 PM, Devananda van der Veen
Maciej,
Maintaining multiple versions of the same package concurrently and
tracking their compatibility with the many different components of
OpenStack and Fuel creates additional work on many different levels,
from spec branch management to repo management to validation to
container building and
In addition,
In the last keystone meeting in March 17 in the IRC channel
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2015-03-17.log
we
decided that Henry Nash (keystone core) will sponsor this feature as a FFE.
Cheers,
Raildo
On Tue, Mar 17, 2015 at 5:36
On Thu, Mar 19, 2015 at 11:24:16AM PDT, Ian Wells wrote:
There are precedents for this. For example, the attributes that currently
exist for IPv6 advertisement are very similar:
I'll also note that the API changes landed in Icehouse, but the
implementation missed the Icehouse deadline and was
Nikunj,
aren't you going to present this talk together with Drago Rosson since he's
the sole developer of Hotbuilder? That would be fair.
Anyways, thanks for advertising Hotbuilder and Merlin :), both me and Drago
have been spending inexcusably too little time spreading the word in the
mailing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/19/2015 10:16 AM, Matthias Runge wrote:
Hello,
I was trying to raise the cap for Django in[1]. It looks quite
simple, current requirements is Django=1.4.2,1.7 and I simply
removed the upper boundary: Django=1.4.2
with the result,
On 03/17/2015 01:59 AM, Smigiel, Dariusz wrote:
On 17 March 2015 at 09:30, Ben Nemec openst...@nemebean.com
wrote:
So I've successfully done a deployment to a QuintupleO environment. \o/
\o/
Great news! Congrats!
@Ben, are you planning to keep it up-to-date or create repo with README?
With regards to the MTU can you please point me to where we validate that the
MTU defined by the tenant is actually = the supported MTU on the network. I
did not see this in the code (maybe I missed something).
From: Ian Wells ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk
Reply-To:
And don't forget about:
https://review.openstack.org/#/c/130047/
Sounds pretty similar (the proxy could proxy to anything, etc.d,
zookeeper, a email system, a snail, a web-service, whatever...).
-Josh
Davanum Srinivas wrote:
Chmouel,
Nice!
Ben added a topic Alternative file formats for
Per the other discussion on attributes, I believe the change walks in
historical footsteps and it's a matter of project policy choice. That
aside, you raised a couple of other issues on IRC:
- backward compatibility with plugins that haven't adapted their API - this
is addressed in the spec,
Hi,
Just the fact that we did this does not make it right. But I guess that we
are starting to bend the rules. I think that we really need to be far more
diligent about this kind of stuff. Having said that we decided the
following on IRC:
1. Mtu will be left in the core (all plugins should be
The glance_store release management team is pleased to announce:
Release of glance_store version 0.4.0
Please find the details related to the release at:
https://launchpad.net/glance-store/+milestone/v0.4.0
Please report the issues through launchpad:
we already have a package with the name fuel-utils please see [1]. I
-1'd the CR over it.
[1] http://lists.openstack.org/pipermail/openstack-dev/2015-March/059206.html
On Thu, Mar 19, 2015 at 7:11 AM, Alexander Kislitsky
akislit...@mirantis.com wrote:
+1 for moving fuel_development into
The python-glanceclient release management team is pleased to announce:
Release of python-glanceclient version 0.17.0
Please find the details related to the release at:
https://launchpad.net/python-glanceclient/+milestone/v0.17.0
Please report the issues through launchpad:
During
http://lists.openstack.org/pipermail/openstack-dev/2015-March/059000.html,
we had some discussions on
whether we need version specific code remaining even we suggest user can
use API version directly in API, [1][2] aiming to remove that
And if we should keep following stuff , then [3][4]
Hi lbaas'ers,
Now that lbaasv2 has shipped, the need for a regular weekly meeting is
greatly reduced. I propose that we cancel the regular meeting, and discuss
neutron-y things during the neutron on-demand agenda, and octavia things in the
already existing octavia meetings.
Any
I have an alternative solution for `rally verify project start` command.
What do you think about similar management stuff for verifiers as we have
for deployments?
It requires several changes:
- `rally verifiers` command: Implementation of new command, which will
manage(install, reinstall,
On 19 March 2015 at 11:44, Gary Kotton gkot...@vmware.com wrote:
Hi,
Just the fact that we did this does not make it right. But I guess that we
are starting to bend the rules. I think that we really need to be far more
diligent about this kind of stuff. Having said that we decided the
?Isn't this argument as to whether those fields should be turned off/on, versus
just always being on? Are there any guidelines as to what fields are allowed
to be added in that base resource attr map? If ML2 needs these and other
fields, should they just always be on?
Thanks,
Brandon
Hi Gary,
First I’m seeing these, but I don’t see that they’re required on input, unless
I’m mis-reading those reviews. Additional of new output fields to a json
object, or adding optional inputs, is not generally considered to be backwards
incompatible behavior in an API. Does OpenStack have
Chmouel,
Nice!
Ben added a topic Alternative file formats for oslo.config for
Liberty[1]. this would be great if we can talk about alternative
backends as well :)
-- dims
[1] https://etherpad.openstack.org/p/liberty-oslo-summit-planning
On Thu, Mar 19, 2015 at 8:31 AM, Chmouel Boudjnah
On Thu, Mar 19, 2015 at 05:37:59AM PDT, Gary Kotton wrote:
In my opinion these should be added as separate extensions.
The spec that was approved for these patches does list the new attribute as
being
added to the Network object.
Hi,
I created and am trying to work on
https://bugs.launchpad.net/openstack-api-site/+bug/1433561.
Is there someone who can advise me on how to create the WADL file for
VPNaaS? I see the LBaaS one and can manually try to convert the old VPNaaS
API documentation to a similar format, using a text
On Wed, Mar 18, 2015 at 11:38 PM, Bharat Kumar
bharat.kobag...@redhat.com wrote:
Regarding the GlusterFS CI:
As I am dealing with end to end CI process of GlusterFS, please modify the
contact person to bharat.kobag...@redhat.com.
Because of this I may miss important announcements from you
71 matches
Mail list logo
