On 12/20/2013 05:51 PM, Clint Byrum wrote:
Excerpts from Ladislav Smola's message of 2013-12-20 05:48:40 -0800:
On 12/20/2013 02:37 PM, Imre Farkas wrote:
On 12/20/2013 12:25 PM, Ladislav Smola wrote:
2. Heat stack create, update
This is locked in the process of the operation, so nobody can
On 21.12.2013 06:10, Jay Pipes wrote:
On 12/20/2013 11:34 AM, Clint Byrum wrote:
Excerpts from Radomir Dopieralski's message of 2013-12-20 01:13:20 -0800:
On 20/12/13 00:17, Jay Pipes wrote:
On 12/19/2013 04:55 AM, Radomir Dopieralski wrote:
On 14/12/13 16:51, Jay Pipes wrote:
[snip]
On 01/02/2014 06:41 AM, Radomir Dopieralski wrote:
On 20/12/13 17:34, Clint Byrum wrote:
OpenStack is non-deterministic. Deterministic systems are rigid and unable
to handle failure modes of any kind of diversity.
I wonder how you are going to debug a non-deterministic system :-)
Very
On 20/12/13 00:17, Jay Pipes wrote:
On 12/19/2013 04:55 AM, Radomir Dopieralski wrote:
On 14/12/13 16:51, Jay Pipes wrote:
[snip]
Instead of focusing on locking issues -- which I agree are very
important in the virtualized side of things where resources are
thinner -- I believe that in the
May I propose we keep the conversation Icehouse related. I don't think
we can make any sort of locking
mechanism in I.
Though it would be worth of creating some WikiPage that would present it
whole in some consistent
manner. I am kind of lost in these emails. :-)
So, what do you thing are
On 20/12/13 12:25, Ladislav Smola wrote:
May I propose we keep the conversation Icehouse related. I don't think
we can make any sort of locking
mechanism in I.
By getting rid of tuskar-api and putting all the logic higher up, we are
forfeiting the ability to ever create it. That worries me. I
On 20/12/13 13:04, Radomir Dopieralski wrote:
[snip]
I have just learned that tuskar-api stays, so my whole ranting is just a
waste of all our time. Sorry about that.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
On 12/20/2013 12:25 PM, Ladislav Smola wrote:
2. Heat stack create, update
This is locked in the process of the operation, so nobody can mess with
it while it is updating or creating.
Once we will pack all operations that are now aside in this, we should
be alright. And that should be doable in
On 12/20/2013 01:04 PM, Radomir Dopieralski wrote:
On 20/12/13 12:25, Ladislav Smola wrote:
May I propose we keep the conversation Icehouse related. I don't think
we can make any sort of locking
mechanism in I.
By getting rid of tuskar-api and putting all the logic higher up, we are
forfeiting
On 12/20/2013 02:06 PM, Radomir Dopieralski wrote:
On 20/12/13 13:04, Radomir Dopieralski wrote:
[snip]
I have just learned that tuskar-api stays, so my whole ranting is just a
waste of all our time. Sorry about that.
Hehe. :-)
Ok after the last meeting we are ready to say what goes to
On 12/20/2013 02:37 PM, Imre Farkas wrote:
On 12/20/2013 12:25 PM, Ladislav Smola wrote:
2. Heat stack create, update
This is locked in the process of the operation, so nobody can mess with
it while it is updating or creating.
Once we will pack all operations that are now aside in this, we
On 12/20/2013 08:40 AM, Ladislav Smola wrote:
On 12/20/2013 02:06 PM, Radomir Dopieralski wrote:
On 20/12/13 13:04, Radomir Dopieralski wrote:
[snip]
I have just learned that tuskar-api stays, so my whole ranting is just a
waste of all our time. Sorry about that.
Hehe. :-)
Ok after the
Excerpts from Radomir Dopieralski's message of 2013-12-20 01:13:20 -0800:
On 20/12/13 00:17, Jay Pipes wrote:
On 12/19/2013 04:55 AM, Radomir Dopieralski wrote:
On 14/12/13 16:51, Jay Pipes wrote:
[snip]
Instead of focusing on locking issues -- which I agree are very
important in
Excerpts from Ladislav Smola's message of 2013-12-20 05:48:40 -0800:
On 12/20/2013 02:37 PM, Imre Farkas wrote:
On 12/20/2013 12:25 PM, Ladislav Smola wrote:
2. Heat stack create, update
This is locked in the process of the operation, so nobody can mess with
it while it is updating or
On 14/12/13 16:51, Jay Pipes wrote:
[snip]
Instead of focusing on locking issues -- which I agree are very
important in the virtualized side of things where resources are
thinner -- I believe that in the bare-metal world, a more useful focus
would be to ensure that the Tuskar API service
On 12/19/2013 04:55 AM, Radomir Dopieralski wrote:
On 14/12/13 16:51, Jay Pipes wrote:
[snip]
Instead of focusing on locking issues -- which I agree are very
important in the virtualized side of things where resources are
thinner -- I believe that in the bare-metal world, a more useful focus
On Wed, 2013-12-11 at 09:32 -0500, Jay Dobies wrote:
On 12/11/2013 07:33 AM, Jiří Stránský wrote:
3) Keep tuskar-api and python-tuskarclient thin, make another library
sitting between Tuskar UI and all python-***clients. This new project
would contain the logic of using undercloud services
On Wed, 2013-12-11 at 17:48 +0100, Jiří Stránský wrote:
snip
When you say python- clients, is there a distinction between the CLI and
a bindings library that invokes the server-side APIs? In other words,
the CLI is packaged as CLI+bindings and the UI as GUI+bindings?
python-tuskarclient =
On Thu, 2013-12-12 at 15:22 +0100, Hugh O. Brock wrote:
On Thu, Dec 12, 2013 at 03:11:14PM +0100, Ladislav Smola wrote:
Agree with this.
Though I am an optimist, I believe that this time, we can avoid
calling multiple services in one request that depend on each other.
About the
On Sat, 2013-12-14 at 10:52 -0500, Tzu-Mainn Chen wrote:
On Wed, 2013-12-11 at 17:48 +0100, Jiří Stránský wrote:
snip
When you say python- clients, is there a distinction between the CLI
and
a bindings library that invokes the server-side APIs? In other words,
the CLI is
On 12.12.2013 17:10, Mark McLoughlin wrote:
On Wed, 2013-12-11 at 13:33 +0100, Jiří Stránský wrote:
Hi all,
TL;DR: I believe that As an infrastructure administrator, Anna wants a
CLI for managing the deployment providing the same fundamental features
as UI. With the planned architecture
On 12.12.2013 17:10, Mark McLoughlin wrote:
On Wed, 2013-12-11 at 13:33 +0100, Jiří Stránský wrote:
Hi all,
TL;DR: I believe that As an infrastructure administrator, Anna wants a
CLI for managing the deployment providing the same fundamental features
as UI. With the planned
On 11/12/13 13:33, Jiří Stránský wrote:
[snip]
TL;DR: I believe that As an infrastructure administrator, Anna wants a
CLI for managing the deployment providing the same fundamental features
as UI. With the planned architecture changes (making tuskar-api thinner
and getting rid of proxying to
On 12.12.2013 11:49, Radomir Dopieralski wrote:
On 11/12/13 13:33, Jiří Stránský wrote:
[snip]
TL;DR: I believe that As an infrastructure administrator, Anna wants a
CLI for managing the deployment providing the same fundamental features
as UI. With the planned architecture changes (making
On 12/12/13 11:49, Radomir Dopieralski wrote:
On 11/12/13 13:33, Jiří Stránský wrote:
[snip]
TL;DR: I believe that As an infrastructure administrator, Anna wants a
CLI for managing the deployment providing the same fundamental features
as UI. With the planned architecture changes (making
On 12.12.2013 14:26, Jiří Stránský wrote:
On 12.12.2013 11:49, Radomir Dopieralski wrote:
On 11/12/13 13:33, Jiří Stránský wrote:
[snip]
TL;DR: I believe that As an infrastructure administrator, Anna wants a
CLI for managing the deployment providing the same fundamental features
as UI. With
Agree with this.
Though I am an optimist, I believe that this time, we can avoid calling
multiple services in one request that depend on each other.
About the multiple users at once, this should be solved inside the API
calls of the services.
So I think we should forbid building these
On Thu, Dec 12, 2013 at 03:11:14PM +0100, Ladislav Smola wrote:
Agree with this.
Though I am an optimist, I believe that this time, we can avoid
calling multiple services in one request that depend on each other.
About the multiple users at once, this should be solved inside the
API calls
On Wed, 2013-12-11 at 13:33 +0100, Jiří Stránský wrote:
Hi all,
TL;DR: I believe that As an infrastructure administrator, Anna wants a
CLI for managing the deployment providing the same fundamental features
as UI. With the planned architecture changes (making tuskar-api thinner
and
Hi all,
TL;DR: I believe that As an infrastructure administrator, Anna wants a
CLI for managing the deployment providing the same fundamental features
as UI. With the planned architecture changes (making tuskar-api thinner
and getting rid of proxying to other services), there's not an obvious
A few clarifications added, next time i'll need to triple-read after
myself :)
On 11.12.2013 13:33, Jiří Stránský wrote:
Hi all,
TL;DR: I believe that As an infrastructure administrator, Anna wants a
CLI for managing the deployment providing the same fundamental features
as UI. With the
Disclaimer: I swear I'll stop posting this sort of thing soon, but I'm
new to the project. I only mention it again because it's relevant in
that I missed any of the discussion on why proxying from tuskar API to
other APIs is looked down upon. Jiri and I had been talking yesterday
and he
On Wed, Dec 11, 2013 at 7:33 AM, Jiří Stránský ji...@redhat.com wrote:
Hi all,
TL;DR: I believe that As an infrastructure administrator, Anna wants a CLI
for managing the deployment providing the same fundamental features as UI.
With the planned architecture changes (making tuskar-api thinner
Thanks for writing this all out!
- Original Message -
Disclaimer: I swear I'll stop posting this sort of thing soon, but I'm
new to the project. I only mention it again because it's relevant in
that I missed any of the discussion on why proxying from tuskar API to
other APIs is looked
On Wed, Dec 11, 2013 at 10:35 AM, James Slagle james.sla...@gmail.com wrote:
On Wed, Dec 11, 2013 at 7:33 AM, Jiří Stránský ji...@redhat.com wrote:
1) Make a thicker python-tuskarclient and put the business logic there. Make
it consume other python-*clients. (This is an unusual approach though,
On Wed, Dec 11, 2013 at 9:35 AM, James Slagle james.sla...@gmail.comwrote:
On Wed, Dec 11, 2013 at 7:33 AM, Jiří Stránský ji...@redhat.com wrote:
Previously, we had planned Tuskar arcitecture like this:
tuskar-ui - tuskarclient - tuskar-api - heat-api|ironic-api|etc.
To be clear,
Hi,
thanks for starting this conversation.
I will take it little side ways. I think we should be asking why have we
needed the tuskar-api. It has done some more complex logic (e.g.
building a heat template) or storing additional info, not supported by
the services we use (like rack
I will take it little side ways. I think we should be asking why have
we needed the tuskar-api. It has done some more complex logic (e.g.
building a heat template) or storing additional info, not supported
by the services we use (like rack associations).
That is a perfectly fine
On 12/11/2013 04:35 PM, James Slagle wrote:
On Wed, Dec 11, 2013 at 7:33 AM, Jiří Stránský ji...@redhat.com wrote:
Hi all,
TL;DR: I believe that As an infrastructure administrator, Anna wants a CLI
for managing the deployment providing the same fundamental features as UI.
With the planned
On 11.12.2013 16:43, Tzu-Mainn Chen wrote:
Thanks for writing this all out!
- Original Message -
Disclaimer: I swear I'll stop posting this sort of thing soon, but I'm
new to the project. I only mention it again because it's relevant in
that I missed any of the discussion on why
On Wed, Dec 11, 2013 at 10:41 AM, Jay Dobies jason.dob...@redhat.comwrote:
I'm still fuzzy on what OpenStack means when it says *client. Is that just
a bindings library that invokes a remote API or does it also contain the
CLI bits?
For the older python-*client projects they are both Python
41 matches
Mail list logo
