Roman,
I am absolutely +1 for re-designing fuel client and bringing it out of
fuel-web repo.
If you ask me, it is also important to make new design following kind of
standard just to avoid re-re-designing it in the foreseeable future. Some
points here are:
0) Rename fuelclient into
Hi,
as discussed at the summit, we want to do a better job of tracking the
progress of work on our priorities for Kilo. To that end, we have
agreed to discuss the current state of these at each nova meeting.
I have created this etherpad:
Le 20/11/2014 10:17, Michael Still a écrit :
Hi,
as discussed at the summit, we want to do a better job of tracking the
progress of work on our priorities for Kilo. To that end, we have
agreed to discuss the current state of these at each nova meeting.
I have created this etherpad:
Hi,
I would like to know about a way of checking replicate completion on swift
cluster.
(e.g. after rebalanced Ring)
I found the way of using swift-dispersion-report from Administrator's Guide.
But, this way is not enough, because swift-dispersion-report can't checking
replicate completion for
On 20/11/14 20:17 +1100, Michael Still wrote:
Hi,
as discussed at the summit, we want to do a better job of tracking the
progress of work on our priorities for Kilo. To that end, we have
agreed to discuss the current state of these at each nova meeting.
I have created this etherpad:
On 20 November 2014 02:19, Sukhdev Kapur sukhdevka...@gmail.com wrote:
Folks,
Like Ian, I am jumping in this very late as well - as I decided to travel
Europe after the summit, just returned back and catching up :-):-)
I have noticed that this thread has gotten fairly convoluted and
On 20 November 2014 09:32, Flavio Percoco fla...@redhat.com wrote:
On 20/11/14 20:17 +1100, Michael Still wrote:
Hi,
as discussed at the summit, we want to do a better job of tracking the
progress of work on our priorities for Kilo. To that end, we have
agreed to discuss the current state
It is quite possible that the requirement for glance to own images can be
achieved by having a glance tenant in cinder, and using clone and
volume-transfer functionalities in cinder to get copies to the right place.
I know there is some attempts to move away from the single glance tenant
model
On 20 November 2014 09:25, Sylvain Bauza sba...@redhat.com wrote:
Le 20/11/2014 10:17, Michael Still a écrit :
Hi,
as discussed at the summit, we want to do a better job of tracking the
progress of work on our priorities for Kilo. To that end, we have
agreed to discuss the current state of
Hi,
As a Fuel user I would like to give some input.
0) This would make fuel adhere to the standards for clients, I agree with
this change.
1) cliff is not really necessary, but is actually being adopted by some
other projects (other than OpenStack unified client) I initially proposed
it for
Le 20/11/2014 11:15, John Garbutt a écrit :
On 20 November 2014 09:25, Sylvain Bauza sba...@redhat.com wrote:
Le 20/11/2014 10:17, Michael Still a écrit :
Hi,
as discussed at the summit, we want to do a better job of tracking the
progress of work on our priorities for Kilo. To that end, we
Nor should it, IMO. Other than the Neutron dhcp-agent, all OpenStack
services that run on a controller node are completely stateless.
Therefore, I don't see any reason to use corosync/pacemaker for management
of these resources.
I see following reasons for managing neutron agents by
Jay S. Bryant wrote:
For those of you that weren't able to make the Kilo meet-up in Paris I
wanted to send out a note regarding Cinder's Kilo mid-cycle meet-up.
IBM has offered to host it in, warm, sunny, Austin, Texas. The planned
dates are January 27, 28 and 29, 2015.
I have put
Kyle Mestery wrote:
We're in the process of writing a spec for this now, but we first
wanted community feedback. Also, it's on the TC agenda for next week I
believe, so once we get signoff from the TC, we'll propose the spec.
Frankly, I don't think the TC really has to sign-off on what seems
On 11/20/2014 05:43 AM, Thierry Carrez wrote:
Kyle Mestery wrote:
We're in the process of writing a spec for this now, but we first
wanted community feedback. Also, it's on the TC agenda for next week I
believe, so once we get signoff from the TC, we'll propose the spec.
Frankly, I don't
Hi,
Per discussion I had at OpenStack Summit/Paris with Brandon and Doug, I would
like to remind everyone why we choose to follow a model where pools and
listeners are shared (many to many relationships).
Use Cases:
1. The same application is being exposed via different LB objects.
For
Hi,
Currently stable branch Jenkins builds are failing due to the error:
Syncing /opt/stack/new/taskflow/requirements-py3.txt
'wrapt' is not a global requirement but it should be,something went wrong
It's my understanding that this is a side effect from your change in taskflow:
Thanks for a reminder, Brandon.
Abandoned
-Original Message-
From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
Sent: Thursday, November 20, 2014 12:39 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron][lbaas] Abandon Old LBaaS V2 Review
Evgeny,
Since
Hi Sergey! Comments inline.
On 11/20/2014 05:25 AM, Sergey Vasilenko wrote:
Nor should it, IMO. Other than the Neutron dhcp-agent, all OpenStack
services that run on a controller node are completely stateless.
Therefore, I don't see any reason to use corosync/pacemaker for
Hey y'all,
To avoid cross-posting, please inform your -infra / -operations buddies about
this post.
We've just started thinking about where notification schema files should live
and how they should be deployed. Kind of a tricky problem. We could really use
your input on this problem ...
Aloha guardians of the API!
I haven recently* reviewed a spec for neutron [1] proposing a distinct URI
for returning resource count on list operations.
This proposal is for selected neutron resources, but I believe the topic is
general enough to require a guideline for the API working group. Your
Hi everyone,
TL;DR:
I propose we turn the weekly project/release meeting timeslot
(Tuesdays at 21:00 UTC) into a weekly cross-project meeting, to
discuss cross-project topics with all the project leadership, rather
than keep it release-specific.
Long version:
Since the dawn of time (August 28,
On 11/20/2014 08:55 AM, Thierry Carrez wrote:
This is mostly a cosmetic change: update the messaging around that
meeting to make it more obvious that it's not purely about the
integrated release and that it is appropriate to put other types of
cross-project issues on the agenda. Let me know on
On 11/20/2014 08:47 AM, Salvatore Orlando wrote:
Aloha guardians of the API!
LOL :)
I haven recently* reviewed a spec for neutron [1] proposing a distinct
URI for returning resource count on list operations.
This proposal is for selected neutron resources, but I believe the topic
is general
On 11/20/2014 09:12 AM, Jay Pipes wrote:
On 11/20/2014 08:47 AM, Salvatore Orlando wrote:
Aloha guardians of the API!
LOL :)
I haven recently* reviewed a spec for neutron [1] proposing a distinct
URI for returning resource count on list operations.
This proposal is for selected neutron
On Thu, 20 Nov 2014 14:47:16 +0100
Salvatore Orlando sorla...@nicira.com wrote:
Aloha guardians of the API!
I haven recently* reviewed a spec for neutron [1] proposing a
distinct URI for returning resource count on list operations.
This proposal is for selected neutron resources, but I
Hi,
Just a reminder that the weekly Nova API meeting is being held tomorrow
Friday UTC .
We encourage cloud operators and those who use the REST API such as
SDK developers and others who and are interested in the future of the
API to participate.
In other timezones the meeting is at:
EST
[pardon my jumping in like kibo, someone mentioned 'client' ;) ]
On Thu, Nov 20, 2014 at 3:01 AM, Vladimir Kozhukalov
vkozhuka...@mirantis.com wrote:
0) Rename fuelclient into python-fuelclient like any other OpenStack
clients when moving it to a separate repo.
1) Use cliff as a cli library.
So as I mentioned in the etherpad I published a spec here
https://review.openstack.org/#/c/135915/
https://review.openstack.org/#/c/135915/
Everyone is welcome to review it.
@Juan: For sure we should use keystone for auth. I might have stated it wrong.
What I mean is that we should use similar
On 19 November 2014 17:19, Sukhdev Kapur sukhdevka...@gmail.com wrote:
Folks,
Like Ian, I am jumping in this very late as well - as I decided to travel
Europe after the summit, just returned back and catching up :-):-)
I have noticed that this thread has gotten fairly convoluted and
Dmitry,
thank you that you raised this important discussion and added section @Test
and report bug.
From my side I want notice, that we have many unclear bugs and sometimes is
very hard to verify such bugs.
The awesome example: https://bugs.launchpad.net/fuel/+bug/1357298
there are many questions
On 11/20/2014 09:04 AM, Russell Bryant wrote:
On 11/20/2014 08:55 AM, Thierry Carrez wrote:
This is mostly a cosmetic change: update the messaging around that
meeting to make it more obvious that it's not purely about the
integrated release and that it is appropriate to put other types of
Dean, thank you for your input.
On 20 Nov 2014, at 15:43, Dean Troyer dtro...@gmail.com wrote:
[pardon my jumping in like kibo, someone mentioned 'client' ;) ]
Now I know for sure how to summon you :)
On Thu, Nov 20, 2014 at 3:01 AM, Vladimir Kozhukalov
vkozhuka...@mirantis.com
Angus,
This may sound crazy but what if in addition to having the online meetup
you denoted two different locations as an optional physical meetup? That
way you would get some of the benefits of having folks meet together in
person while not forcing everyone to have to travel across the
On Thursday, November 20, 2014, Anita Kuno ante...@anteaya.info wrote:
On 11/20/2014 09:04 AM, Russell Bryant wrote:
On 11/20/2014 08:55 AM, Thierry Carrez wrote:
This is mostly a cosmetic change: update the messaging around that
meeting to make it more obvious that it's not purely about
Hi, we had an interesting discussion on IRC about whether or not we should
be maintaining backwards compatibility within a release cycle. In this
particular case, we introduced a new decorator in this kilo cycle, and were
discussing the renaming of it, and whether it needed to be backwards
This looks very cool!!! Is it ready for the rest of the other projects to
start using as well?
Thanks,
Brad
Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet: bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680
From: Michael Krotscheck
Hey there, Brad!
The answer to your question depends on who you ask. If you ask me, I will say:
Yes! Feel free to use it all you want! If you ask Thierry or Jim Blair, their
response will be “Oh please no”.
Our roadmap right now is as follows:
- 1.1.1: Clean up straggling features from our
Hi all,
Swift Browser 0.2.0 has been released:
https://github.com/zerovm/swift-browser/releases/tag/0.2.0
This release adds support for copying objects and deleting containers.
Furthermore, the JavaScript and CSS files are now concatenated and
minified, resulting in a faster page load.
You
On Thu, Nov 20, 2014 at 6:42 AM, Russell Bryant rbry...@redhat.com wrote:
On 11/20/2014 05:43 AM, Thierry Carrez wrote:
Kyle Mestery wrote:
We're in the process of writing a spec for this now, but we first
wanted community feedback. Also, it's on the TC agenda for next week I
believe, so once
The Nova proposal appears to be identical to neutron's, at least from a
consumer perspective.
If I were to pick a winner, I'd follow Sean's advice regarding the 'more'
attribute in responses, and put the total number of resources there; I
would also take Jay's advice of including the total only
Hi Ruby,
Thank you for putting this up.
I'm one of the ones think we should try hard (even really hard) to
maintain the compatibility on every commit. I understand that it may
sound naive because I'm sure that sometimes we will break things, but
that doesn't means we shouldn't try.
There may be
The only thing I want to caution against is making a SQL-specific choice. In
the case of some other backends, it may not be possible (for an extremely large
dataset) to get a full count, where SQL does this fairly elegantly. For
example, LDAP (in some cases) may have an administrative limit
On Thu, 2014-11-20 at 08:28 -0800, Morgan Fainberg wrote:
The only thing I want to caution against is making a SQL-specific
choice. In the case of some other backends, it may not be possible
(for an extremely large dataset) to get a full count, where SQL does
this fairly elegantly. For
I'm looking at the Nova spec, and it seems very taylored to a specific
GUI. I'm also not sure that 17128 errors is more useful than 500+ errors
when presenting to the user (the following in my twitter stream made me
think about that this morning -
Hi all,
Recently there’s been quite a bit of interest in adding reactive enforcement to
Congress: the ability to write policies that tell Congress to execute actions
to correct policy violations. We’re planning to add this feature in the next
release. I wrote a few specs that split this work
On 11/17/2014 06:54 PM, Radomir Dopieralski wrote:
- A tool, probably a script, that would help packaging the Bower
packages into DEB/RPM packages. I suspect the Debian/Fedora packagers
already have a semi-automatic solution for that.
Nop. Bower isn't even packaged in Debian. Though I may try
Thank you for this Ruby,
I agree with what Lucas stated in his reply, Though I thought I would toss
my two cents in to the pool as well.
I also feel that we should (and have been) strive (ing) to maintain
compatibility. Though I feel this is more important on a release to release
basis, more so
On Thu, Nov 20, 2014 at 9:30 AM, Roman Prykhodchenko
rprikhodche...@mirantis.com wrote:
I think this is not very reasonable because Fuel does not provide any
service in OpenStack but instead allows to set up and manage OpenStack
clusters.
Ah, well that is different. FWIW, I have done this
Thanks for the summary Greg—that was great! Here’s my take.
It would be great if all the services Congress interacts with implemented the
same protocol and used the same policy/data language. It is worth our time to
figure out what that protocol and language should be.
But we should not
On 11/20/2014 04:38 PM, Ruby Loo wrote:
Hi, we had an interesting discussion on IRC about whether or not we
should be maintaining backwards compatibility within a release cycle. In
this particular case, we introduced a new decorator in this kilo cycle,
and were discussing the renaming of it, and
Let's get concrete for a moment, because it makes a difference which API
we're talking about.
We have to guarantee a fairly high degree of backwards compatibility within
the REST API. Adding new capabilities, and exposing them in a discoverable
way, is fine; a backwards-incompatible breaking
Hi everyone,
TL;DR:
I propose we turn the weekly project/release meeting timeslot
(Tuesdays at 21:00 UTC) into a weekly cross-project meeting, to
discuss cross-project topics with all the project leadership, rather
than keep it release-specific.
Long version:
Since the dawn of
I think it depends totally on if you want trunk to be a distribution mechanism
or not. If you encourage people to 'just use trunk' for deployment, then you
better not break out of tree drivers on people. If you have a stable release
branch, that you tell people to use, there is plenty of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19/11/14 18:39, Dan Smith wrote:
However, it presents a problem when we consider NovaObjects, and
dependencies between them.
I disagree with this assertion, because:
For example, take Instance.save(). An Instance has relationships
with
Hiya,
I'm going to step away from TripleO for a while to refocus on Nova. No
reflection on TripleO, this is to align with my local team. It's been a
pleasure working with all of you, I hope I've had some kind of positive
impact and I'm sure we'll still bump into one another now and then.
Alexis
On Thu, Nov 20, 2014 at 9:25 AM, Anita Kuno ante...@anteaya.info wrote:
On 11/20/2014 09:04 AM, Russell Bryant wrote:
On 11/20/2014 08:55 AM, Thierry Carrez wrote:
This is mostly a cosmetic change: update the messaging around that
meeting to make it more obvious that it's not purely about the
You might check if the swift-recon tool has the data you're looking for.
It can report the last completed replication pass time across nodes in the
ring.
On Thu, Nov 20, 2014 at 1:28 AM, Matsuda, Kenichiro
matsuda_keni...@jp.fujitsu.com wrote:
Hi,
I would like to know about a way of checking
* Flavor.save() makes an unbounded number of db calls in separate
transactions.
This is actually part of the design of the original flavors public API.
Since we can add and remove projects/specs individually, we avoid ending
up with just one or the other group of values, for competing requests.
On Nov 20, 2014, at 8:12 AM, Sandy Walsh sandy.wa...@rackspace.com wrote:
Hey y'all,
To avoid cross-posting, please inform your -infra / -operations buddies about
this post.
We've just started thinking about where notification schema files should live
and how they should be deployed.
Hi folks,
There was interesting research today on random nics ordering for nodes in
bootstrap stage. And in my opinion it requires separate thread...
I will try to describe what the problem is and several ways to solve it.
Maybe i am missing the simple way, if you see it - please participate.
The neturon spec appears to be a copy/paste of the nova spec that I wrote.
Based on the conversation below, I agree that this is not the best
approach: GET /prefix/resource_name/count
I'll get started on updating the nova spec to include the total count value
in some new attribute based on the
On Nov 20, 2014, at 12:19 PM, Eoghan Glynn egl...@redhat.com wrote:
Hi everyone,
TL;DR:
I propose we turn the weekly project/release meeting timeslot
(Tuesdays at 21:00 UTC) into a weekly cross-project meeting, to
discuss cross-project topics with all the project leadership, rather
Guys, maybe we can use existing software, for example Sensu [1]?
Maybe i am wrong, but i dont like the idea to start writing our small
monitoring applications..
Also something well designed and extendable can be reused for statistic
collector
1. https://github.com/sensu
On Wed, Nov 12, 2014 at
Minutes:
*http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-11-20-18.01.html
http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-11-20-18.01.html*
Logs:
*http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-11-20-18.01.log.html
Hi Sukhdev,
Hope you enjoyed Europe ;)
On 19 November 2014 17:19, Sukhdev Kapur sukhdevka...@gmail.com wrote:
Folks,
Like Ian, I am jumping in this very late as well - as I decided to travel
Europe after the summit, just returned back and catching up :-):-)
I have noticed that this
On 20 November 2014 02:08, Salvatore Orlando sorla...@nicira.com wrote:
On 20 November 2014 02:19, Sukhdev Kapur sukhdevka...@gmail.com wrote:
Folks,
Like Ian, I am jumping in this very late as well - as I decided to travel
Europe after the summit, just returned back and catching up
From: Doug Hellmann [d...@doughellmann.com] Thursday, November 20, 2014 3:51 PM
On Nov 20, 2014, at 8:12 AM, Sandy Walsh sandy.wa...@rackspace.com wrote:
Hey y'all,
To avoid cross-posting, please inform your -infra / -operations buddies
about this post.
We've just started
On Nov 20, 2014, at 3:40 PM, Sandy Walsh sandy.wa...@rackspace.com wrote:
From: Doug Hellmann [d...@doughellmann.com] Thursday, November 20, 2014 3:51
PM
On Nov 20, 2014, at 8:12 AM, Sandy Walsh sandy.wa...@rackspace.com wrote:
Hey y'all,
To avoid cross-posting, please inform your -infra
On 11/19/14, 5:02 PM, Kyle Mestery mest...@mestery.com wrote:
On Tue, Nov 18, 2014 at 5:32 PM, Doug Wiegley do...@a10networks.com
wrote:
Hi,
so the specs repository would continue to be shared during the Kilo
cycle.
One of the reasons to split is that these two teams have different
Thanks for raising this Sandy,
Some questions/observations inline.
Hey y'all,
To avoid cross-posting, please inform your -infra / -operations buddies about
this post.
We've just started thinking about where notification schema files should live
and how they should be deployed. Kind
Hi everyone,
Earlier today https://review.openstack.org/136017 merged which adds stable
compat jobs to most of the oslo libraries. This was done in reaction to 2
separate incidents in the past 2 days where both oslo.vmware and taskflow landed
changes that added new requirements which weren't in
+1 for Dima's suggestion. We need to stop reinventing the wheel. There
are a lot tools around us, so let's pick one of them and will use it.
On Thu, Nov 20, 2014 at 10:13 PM, Dmitriy Shulyak dshul...@mirantis.com wrote:
Guys, maybe we can use existing software, for example Sensu [1]?
Maybe i am
On Thu, Nov 20, 2014 at 9:49 AM, Sahid Orentino Ferdjaoui
sahid.ferdja...@redhat.com wrote:
This is something we can call nitpiking or low priority.
This all seems like nitpicking for very little value. I think there are
better things we can be focusing on instead of thinking of new ways to
Aloha guardians of the API!
I haven recently* reviewed a spec for neutron [1] proposing a distinct URI
for returning resource count on list operations.
This proposal is for selected neutron resources, but I believe the topic is
general enough to require a guideline for the API working
+1 also. There are so many monitoring tools, but maybe not something
written in ruby ;)
On Thu, Nov 20, 2014 at 10:40 PM, Igor Kalnitsky
ikalnit...@mirantis.com wrote:
+1 for Dima's suggestion. We need to stop reinventing the wheel. There
are a lot tools around us, so let's pick one of them and
I would rather compare features than ruby vs python.
Best Regards,
Sergii Golovatiuk
On 20 Nov 2014, at 23:20, Lukasz Oles lo...@mirantis.com wrote:
+1 also. There are so many monitoring tools, but maybe not something
written in ruby ;)
On Thu, Nov 20, 2014 at 10:40 PM, Igor Kalnitsky
Thanks, hopefully this helps in the short-term before we have the whole
pinning situation worked out and implemented and such (which I believe
is underway). These jobs will help make sure myself (and others) are
aware of the things happening on stable icehouse and such; prior it
wasn't so
Hi
I have a question on
/rally/openstack/common/periodic_task.py
It looks like if I have a method decorated with @periodic_task my method would
get scheduled in separate process every N seconds
Now let us say we have a scenario and this periodic_task how does it work when
concurrency=2 for
On Thu, Nov 20, 2014 at 11:28 PM, Sergii Golovatiuk
sgolovat...@mirantis.com wrote:
I would rather compare features than ruby vs python.
It make sense only as long as you don't need to debug it
Best Regards,
Sergii Golovatiuk
On 20 Nov 2014, at 23:20, Lukasz Oles lo...@mirantis.com
Hi,
We can use keystone-manage token_flush to DELETE db-records of expired tokens.
Similarly, expired or deleted trust should be flushed to avoid wasting db.
But I don't know the way to do so.
Is there any tools or patches?
If there are some reasons that these records must not be deleted
If you have not updated the interest sheet (or if your interest has changed)
please do so TODAY. Let your top 3 interests on the interest tab of the
spreadsheet.
https://docs.google.com/a/vmware.com/spreadsheets/d/1w01Z5J_XvTjbWBvPJ3SgzaQ9nXzOxSVVTGDjQtxAMZA/edit#gid=0
Tracy
In order for this to occur, this means that the node has to be
bootstrapped and discover to nailgun, added to a cluster, and then
bootstrap again (reboot) and have the agent update with a different
nic order?
i think the issue will only occur when networks are mapped to the
interfaces, in this
Wrong mailing list?
Weijin
From: Tracy Jones tjo...@vmware.commailto:tjo...@vmware.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, November 20, 2014 at 4:26 PM
To: OpenStack
This seems to be a private doc... if its for public consumption
perhaps change the ACLS ?
-Rob
On 21 November 2014 13:26, Tracy Jones tjo...@vmware.com wrote:
If you have not updated the interest sheet (or if your interest has changed)
please do so TODAY. Let your top 3 interests on the
My primary concern (and use of the numbers) was to make sure it isn’t expected
on all “list” operations, as (albeit specifically for Keystone) some of the
projects + backends can’t really support it. If we really are tied to SQL-isms
(which is a fine approach) we can make these consistent where
Could this be caused by a case mismatch between the MAC address as it
exists in the database and the MAC that comes from the agent?
When the interfaces are updated with data from the agent we attempt to
match the MAC to an existing interface (
On Fri Nov 21 2014 at 4:06:51 AM Thomas Goirand z...@debian.org wrote:
On 11/17/2014 06:54 PM, Radomir Dopieralski wrote:
- A tool, probably a script, that would help packaging the Bower
packages into DEB/RPM packages. I suspect the Debian/Fedora packagers
already have a semi-automatic
Hi Ajay,
I am not sure why you are looking that part at all.
everything in openstack/common/* is oslo-incubator code.
Actually that method is not used in Rally yet, except Rally as a Service
part that doesn't work yet.
As a scenario developer I think you should be able to find everything here:
https://github.com/stackforge/wsme/blob/0.6.2/setup.py (also in master)
File /usr/lib64/python2.7/site-packages/wsme/types.py, line 15, in
module
import ipaddr as ipaddress
https://github.com/stackforge/wsme/blob/master/wsme/types.py#L12-L15
--
-- Matthew Thode
Ok the action I wanted to perform was for HA I.e execute a scenario like VM
boot and in parallel in a separate process , ssh and restart controller node
for instance
I thought periodic task would be useful for that. I guess I need to look at
some other way of performing this
Ajay
From: Boris
On 11/21/2014 10:52 AM, Richard Jones wrote:
On 11/18/2014 04:22 PM, Radomir Dopieralski wrote:
If we use Bower, we don't need to use Xstatic. It would be pure
overhead. Bower already takes care of tracking releases and versions,
and of bundling the files. All we need is a
Hi,
Thank you for the info.
I was able to get replication info easily by swift-recon API.
But, I wasn't able to judge whether no failure from recon info of
object-replicator.
Could you please advise me for a way of get object-replicator's failure info?
[replication info from recon]
* account
On 21 November 2014 16:12, Thomas Goirand z...@debian.org wrote:
On 11/21/2014 10:52 AM, Richard Jones wrote:
On 11/18/2014 04:22 PM, Radomir Dopieralski wrote:
If we use Bower, we don't need to use Xstatic. It would be pure
overhead. Bower already takes care of tracking
On Fri, Nov 14, 2014 at 09:43:45AM +0100, Thierry Carrez wrote:
Thanks Thierry
If you are after the list of distributions with a well-known packaging
of OpenStack then yes, the union of those two lists + Gentoo sounds
accurate to me.
I have to admit I expect this to be a litle more
Hi All,
I am new to Murano trying to implement on Openstack Juno with Ubuntu 14.04 LTS
version. However It needs puka 0.7 as dependency.
I would appreciate any help with the build guides. I also find Github prompts
for username and password while I try installing packages.
Warm Regards,
When the interfaces are updated with data from the agent we attempt to
match the MAC to an existing interface (
https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/network/manager.py#L682-L690).
If that doesn't work we attempt to match by name. Looking at the data that
comes
Hi,
Thanks for providing us great feedback at the summit in Paris! It was really
great to see so many people coming to our sessions and interested in Mistral
capabilities. I’ve tried to do my best to digest all I heard from you and
materialise all the wishes in form of blueprints at Launchpad.
98 matches
Mail list logo
