+1, no objections from my side.
On Fri, Jan 23, 2015 at 6:04 PM, Roman Prykhodchenko m...@romcheg.me wrote:
Hi folks!
After moving python-fuelclient to its own repo some of you started asking a
good question which is How do we manage core rights in different Fuel
repositories. The problem
Ihar Hrachyshka ihrac...@redhat.com wrote:
On 01/23/2015 05:38 PM, Mike Bayer wrote:
Doug Hellmann d...@doughellmann.com wrote:
We put the new base class for RequestContext in its own library because
both the logging and messaging code wanted to influence it's API. Would
it make sense to
How should we deal with release management?
Currently I don't do any merges for stackforge/fuel-* projects but I
need access to all of them to create branches at Hard Code Freeze.
Should we create separate fuel-release group for that? Should it be
unified group for all repositories or every
This thread is created in regard to newly introduced EC2 API standalone
service effort which is covered by the following:
Blueprint:
https://blueprints.launchpad.net/nova/+spec/ec2-api
Nova spec:
https://review.openstack.org/#/c/147882
Project and code:
https://github.com/stackforge/ec2-api
On 01/23/2015 05:38 PM, Mike Bayer wrote:
Doug Hellmann d...@doughellmann.com wrote:
We put the new base class for RequestContext in its own library because
both the logging and messaging code wanted to influence it's API. Would
it make sense to do this database setup there, too?
whoa,
Maybe I'm misunderstanding the issue?
I thought the reason there is no version check currently, is because a
check is being made to see if the process is in the same namespace as root
for the net namespace (as a proxy to checking that the mount namespace is
being used).
The comment indicates
Hello!
Current situation with SQLite support:
- Migration tests does not run on SQLIte.
- At the same time migrations themselves support SQLite (with bugs).
Today I came across this bug:
Error during execution of database downgrade
https://bugs.launchpad.net/murano/+bug/1399151
We can
On Fri, Jan 23, 2015, at 12:49 PM, Mike Bayer wrote:
Mike Bayer mba...@redhat.com wrote:
Ihar Hrachyshka ihrac...@redhat.com wrote:
On 01/23/2015 05:38 PM, Mike Bayer wrote:
Doug Hellmann d...@doughellmann.com wrote:
We put the new base class for RequestContext in its
Unfortunately, I didn't get a feature freeze exception for this blueprint.
I will resubmit the spec in next cycle.
I think the best way for you to contribute is to review the spec,
when it's re-posted and +1 it, if you agree with the design.
Thanks,
Vladik
- Original Message -
From:
The example you put implicitly assigns the status tree to a load balancer.
Is sharing only allowed for sub resources? Or can sub resources be shared
across multiple load balancers? If that is the case then I suspect that
statuses may be exposed in many different places correct?
Cheers,
--Jorge
Doug Hellmann d...@doughellmann.com wrote:
We put the new base class for RequestContext in its own library because
both the logging and messaging code wanted to influence it's API. Would
it make sense to do this database setup there, too?
whoa, where’s that? is this an oslo-wide
+1
On Fri, Jan 23, 2015 at 7:45 PM, Igor Kalnitsky ikalnit...@mirantis.com
wrote:
+1, no objections from my side.
On Fri, Jan 23, 2015 at 6:04 PM, Roman Prykhodchenko m...@romcheg.me
wrote:
Hi folks!
After moving python-fuelclient to its own repo some of you started
asking a good
Hi Folks,
Is there any support yet in novaclient for requesting a specific microversion ?
(looking at the final leg of extending clean-shutdown to the API, and
wondering how to test this in devstack via the novaclient)
Phil
Hi!
As I know, there is no support of microversions in novaclient. Only
os-compute-api-version is supported, but it do nothing(and I start a thread
to clarify this question -
http://lists.openstack.org/pipermail/openstack-dev/2015-January/055027.html)
On Fri, Jan 23, 2015 at 6:53 PM, Day, Phil
Mike Bayer mba...@redhat.com wrote:
Ihar Hrachyshka ihrac...@redhat.com wrote:
On 01/23/2015 05:38 PM, Mike Bayer wrote:
Doug Hellmann d...@doughellmann.com wrote:
We put the new base class for RequestContext in its own library because
both the logging and messaging code wanted to
Based upon the feedback to this thread, I want to congratulate Brad Topol as
the newest member of the Keystone-Specs-Core team!
—Morgan
On Jan 18, 2015, at 11:11 AM, Morgan Fainberg morgan.fainb...@gmail.com
wrote:
Hello all,
I would like to nominate Brad Topol for Keystone Spec core
I have been trying to set up LBaaS v2 in a juno-based environment.
I have successfully done this in devstack by setting it up based on
stable/juno, then grabbing https://review.openstack.org/#/c/123491/ and the
client from https://review.openstack.org/#/c/111475/, and then editing
neutron.conf
Hi, all,
As you may know, Fuel 6.0 has an ability to deploy either a KVM-oriented
environment or a VMware vCenter-oriented environment. We wants to go
further and mix them together. A user should be able to run both
hypervisors in one OpenStack environment. We want to get it in Fuel 6.1.
Here is
On Jan 22, 2015, at 12:21 PM, Kyle Mestery mest...@mestery.com wrote:
On Thu, Jan 15, 2015 at 4:31 PM, Kyle Mestery mest...@mestery.com
mailto:mest...@mestery.com wrote:
The last time we looked at core reviewer stats was in December [1]. In
looking at the current stats, I'm going to
Get ready to vomit.
The lbaasv2 code you’re pulling is a non-agent driver. Meaning, it runs
haproxy on the *neutron controller* node, and only the controller node.
It’s meant to be a POC for single node systems, not something you can
deploy.
In the upcoming mid-cycle, the driver will be
On 19:44 Thu 22 Jan , D'Angelo, Scott wrote:
Thanks to everyone who commented on the spec to change reset-state to involve
the driver: https://review.openstack.org/#/c/134366/
I've put some comments in reply, and I'm going to attempt to capture the
various ideas here. I hope we can
Hi Andrew,
I understand the difficulties with SQLite support, but this is very useful
for development to have SQLite instead of any other DB. I think nodoby uses
SQLite in production, so probably we can just put a release note that there
is a know limitation with SQLite support.
Thanks
Gosha
On
On 2015-01-23 12:02:19 +0100 (+0100), Matthias Runge wrote:
[...]
I think providing/updating distro packages is quite comparable to
updating pypi packages.
[...]
Within an order of magnitude anyway. The difference is that most
Python module upstream authors do their own packaging for PyPI (for
On 11:30 Fri 23 Jan , Bharat Kumar wrote:
Liu,
Yes, by default DevStack configures cinder with LVM. But we can
customize DevStack to configure cinder with our own backend (real
storage backend).
Below is the link to the path, enables Automatic Configuration of
GlusterFS for Cinder
Doug Hellmann d...@doughellmann.com wrote:
On Fri, Jan 23, 2015, at 12:49 PM, Mike Bayer wrote:
Mike Bayer mba...@redhat.com wrote:
Ihar Hrachyshka ihrac...@redhat.com wrote:
On 01/23/2015 05:38 PM, Mike Bayer wrote:
Doug Hellmann d...@doughellmann.com wrote:
We put the new base
Hi Sachi,
This refers to a Neutron Network UUID. This option is available with
the Neutron Resource Mapping Driver. I do not believe it is currently
functional with the ODL driver.
Thanks,
~Sumit.
On Fri, Jan 23, 2015 at 1:04 AM, Sachi Gupta sachi.gu...@tcs.com wrote:
Hi Yapeng, Sumit,
In
On Fri, Jan 23, 2015 at 9:04 PM, Andrew Pashkin apash...@mirantis.com wrote:
Hello!
Current situation with SQLite support:
- Migration tests does not run on SQLIte.
- At the same time migrations themselves support SQLite (with bugs).
Today I came across this bug:
Error during execution of
It's worth noting that all Neutron ML2 drivers are required to move to
their own repos starting in Kilo so installing an extra python package to
use a driver will become part of the standard Neutron installation
workflow. So I would suggest creating a stackforge project for the vDS
driver and
Steven,
Thanks for this email to capture and relay this decision from our IRC team
meeting this week! I thought it might be helpful if I made a team calendar with
an iCal feed that our team can subscribe to that would include our team meeting
schedule, and our milestones to help make our plans
No, AFAICT it's not supported because the v2.1 microversion and related bp
are still under implementation ,there is no change on novaclient now ...
Best Regards!
Kevin (Chen) Ji 纪 晨
Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
Phone:
Eric,
Thanks for your participation, and your help to form the vision for how to get
the containers world and OpenStack to fit together better. We really appreciate
it! I echo your sentiment of appreciation for the whole team as well, several
of which who have stepped up to contribute in a big
Nice work, Brian!
On Thu, Jan 22, 2015 at 2:57 PM, Brian Haley brian.ha...@hp.com wrote:
On 01/22/2015 02:35 PM, Kevin Benton wrote:
Right, there are two bugs here. One is in whatever went wrong with
defer_apply
and one is with this exception handling code. I would allow the fix to go in
What happens if you deploy multiple Neutron servers?
On Fri, Jan 23, 2015 at 10:56 AM, Doug Wiegley do...@a10networks.com
wrote:
Get ready to vomit.
The lbaasv2 code you’re pulling is a non-agent driver. Meaning, it runs
haproxy on the *neutron controller* node, and only the controller
Keystone cores and ATC's,
Thank you very much for the nomination and your positive feedback. I
feel very honored to have receive this nomination. I have thoroughly
enjoyed collaborating with all of you for these past several years. I
look forward to our continued collaboration and am
On 01/23/2015 02:46 PM, Adrian Otto wrote:
Steven,
Thanks for this email to capture and relay this decision from our IRC team
meeting this week! I thought it might be helpful if I made a team calendar with
an iCal feed that our team can subscribe to that would include our team meeting
I've mentioned this in passing a few times, but I want to lay it out
here in a bit more detail for comment. Basically we're implementing
convergence at a time when we still have a lot of 'unit' tests that are
really integration tests, and we don't want to have to rewrite them to
anticipate
On 01/22/2015 06:40 PM, Salvatore Orlando wrote:
I also like the idea of considering the RPC interface. What kind of
stability / versioning exists on the Neutron RPC interface?
Even if Neutron does not have fancy things such as objects with
remotable method, I think its RPC
Hi everyone!
After removing nova V3 API from novaclient[1], implementation of v1.1
client is used for v1.1, v2 and v3 [2].
Since we moving to micro versions, I wonder, do we need such mechanism of
choosing api version(os-compute-api-version) or we can simply remove it,
like in proposed change -
Hi Yapeng, Sumit,
In Openstack GBP command line, for l2policy help, there is an argument
--network that can be passed. Can you please elaborate on which network do
we need to pass here and what is the use of the same.
gbp l2policy-create --help
usage: gbp l2policy-create [-h] [-f
On Sat, Jan 24, 2015 at 01:48:32AM +0100, Thomas Goirand wrote:
I've just noticed that oslo.log made it to global-requirements.txt 9
days ago. How come are we still adding some name.spaced oslo libs?
Wasn't the outcome of the discussion in Paris that we shouldn't do that
anymore, and that we
On Fri, Jan 23, 2015, at 07:48 PM, Thomas Goirand wrote:
Hi,
I've just noticed that oslo.log made it to global-requirements.txt 9
days ago. How come are we still adding some name.spaced oslo libs?
Wasn't the outcome of the discussion in Paris that we shouldn't do that
anymore, and that we
It seems like a change to using internal RPC interfaces would be pretty
unstable at this point.
Can we start by identifying the shortcomings of the HTTP interface and see
if we can address them before making the jump to using an interface which
has been internal to Neutron so far?
I scanned
Aleksandra,
a general practice is to have program-core and program-milestone groups. That
approach fits for fuel-* as well because there’s only one separate team that
does releases for all projects.
What other folks think about that?
- romcheg
23 січ. 2015 о 18:36 Aleksandra Fedorova
Hi,
I've just noticed that oslo.log made it to global-requirements.txt 9
days ago. How come are we still adding some name.spaced oslo libs?
Wasn't the outcome of the discussion in Paris that we shouldn't do that
anymore, and that we should be using oslo-log instead of oslo.log?
Is three
23.01.15, 13:22, Elena Ezhova ?:
On Fri, Jan 23, 2015 at 1:55 PM, Ilya Pekelny ipeke...@mirantis.com
mailto:ipeke...@mirantis.com wrote:
On Fri, Jan 23, 2015 at 12:46 PM, ozamiatin
ozamia...@mirantis.com mailto:ozamia...@mirantis.com wrote:
IMHO It should be created
On 2015-01-23 10:11:46 +0100 (+0100), Matthias Runge wrote:
[...]
It would be totally awesome to switch from pip install to using
distribution packages for testing purposes. At least for
dependencies.
[...]
While it seems nice on the surface, the unfortunate truth is that
neither the infra
On Thu, Jan 22, 2015 at 10:57 PM, Brian Haley brian.ha...@hp.com wrote:
On 01/22/2015 02:35 PM, Kevin Benton wrote:
Right, there are two bugs here. One is in whatever went wrong with
defer_apply
and one is with this exception handling code. I would allow the fix to go in
for
the exception
I also wanted to add that there is a PR already on adding plugins
repos to stackforge: https://review.openstack.org/#/c/147169/
There is a battle in comments right now, because some people are not
agree that so many repos are needed.
On Fri, Jan 23, 2015 at 1:25 AM, Mike Scherbakov
On Thu, Jan 22, 2015 at 09:18:46PM +, Jeremy Stanley wrote:
On 2015-01-22 16:06:55 -0500 (-0500), Matthew Farina wrote:
[...]
When there is an update to our requirements, such as the recent
version increment in the version of angular used, a new package
version doesn't automatically
Hi Fuelers and Mike,
I'd like to provide some ideas/comments for the issues Mike has put into
discussion.
Yesterday we had a nice discussion for plugins SDK.
According to this discussion, we should create an internal document for
plugins certification ASAP (I mean, steps to perform on the
What sort of specification are you talking about here -- specs for
individual plugins
or a spec for how to implement a plugin? If the latter, what is the
relationship of that
to the official documentation about how to create a plugin (to be added to
the
Developer Guide)?
meg
On Fri, Jan 23,
Hi Mike,
All of the items look nice. I have a small comment regarding to the docs.
I don't think that we should force plugin developer to write the docs in
Sphinx compatible format, I vote for Github compatible docs format,
and in case if we want to show this information somewhere else,
we can
Hi,
Working on zmq driver I've noticed that for now zmq.Context is created
per socket which is definitely redundant. That was introduced by the change
https://review.openstack.org/#/c/126914/5/oslo/messaging/_drivers/impl_zmq.py
It makes the correct thing reducing the global context
On Fri, Jan 23, 2015 at 1:55 PM, Ilya Pekelny ipeke...@mirantis.com wrote:
On Fri, Jan 23, 2015 at 12:46 PM, ozamiatin ozamia...@mirantis.com
wrote:
IMHO It should be created once per Reactor/Client or even per driver
instance.
Per driver, sounds good.
Wouldn't this create regression
On Fri, Jan 23, 2015 at 12:46 PM, ozamiatin ozamia...@mirantis.com wrote:
IMHO It should be created once per Reactor/Client or even per driver
instance.
Per driver, sounds good.
By the way (I didn't check it yet with current implementation of the
driver) such approach should break the
On 23/01/15 10:31, Jeremy Stanley wrote:
On 2015-01-23 10:11:46 +0100 (+0100), Matthias Runge wrote:
[...]
It would be totally awesome to switch from pip install to using
distribution packages for testing purposes. At least for
dependencies.
[...]
While it seems nice on the surface, the
To summarize, should we...
A) Assume all kernels will be 3.8+ and use mount namespace (risky?)
B) Do a check to ensure kernel is 3.8+ and fall back to net namespace and
mount --bind if not (more work).
C) Just use net namespace as indication that namespace with mount --bind
done (simple)
Maybe
__In review and merged this past week__
About 60 doc patches merged in the last week, including NUMA Topology
Filter docs, firewall introduction in the new Networking Guide, updates for
the CLI Ref for Ironic 0.3.3 client, and more updates to the Object Storage
portion of the End User Guide. Thank
Mike,
I also wanted to add that there is a PR already on adding plugins
repos to stackforge: https://review.openstack.org/#/c/147169/
All this looks good, but it’s not clear when this patch will be merged and
repos are created.
So the question is what should we do with the current spec made
On Thu, Jan 22, 2015 at 04:09:09PM -0700, Vignesh Kumar wrote:
I am new to heat orchestration and am trying to create a coreOS cluster
with it. I have a OS::Heat::SoftwareConfig resource and a
OS::Heat::CloudConfig resource and I have joined them both in a
OS::Heat::MultipartMime resource
Hi folks!
After moving python-fuelclient to its own repo some of you started asking a
good question which is How do we manage core rights in different Fuel
repositories. The problem is that there is a single fuel-core group which is
used for all fuel-* repos, except for python-fuelclient.
The
On Thu, Jan 22, 2015, at 10:36 AM, Mike Bayer wrote:
Hey all -
Concerning the enginefacade system, approved blueprint:
https://review.openstack.org/#/c/125181/
which will replace the use of oslo_db.sqlalchemy.EngineFacade ultimately
across all projects that use it (which is, all of
According to the patch author, the check isn't necessary at all.
On Fri, Jan 23, 2015 at 7:12 AM, Paul Michali p...@michali.net wrote:
To summarize, should we...
A) Assume all kernels will be 3.8+ and use mount namespace (risky?)
B) Do a check to ensure kernel is 3.8+ and fall back to net
Another ‘sample’ you can use is here:
https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L2
Ramy
From: Bharat Kumar [mailto:bharat.kobag...@redhat.com]
Sent: Thursday, January 22, 2015 10:01 PM
To: openstack-dev@lists.openstack.org
Folks -
I support the idea to keep plugins' code and other artifacts, e.g. design
specs, installation and user guides, test scripts, test plan, test report,
etc, in one repo, just to create dedicated folders for that.
My argument here is pretty simple, i consider a Fuel plugin as a separate
and
65 matches
Mail list logo
