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 me
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]
Inste
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 carefu
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 :-)
> We tend to err toward
> pushing problems back to the user and
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]
Instead of focusing on locking issues -- whi
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 upda
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
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 l
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 shoul
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 Tusk
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 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 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
OpenStack-dev@lists.openstack
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.
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 the
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
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 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 servic
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:
> >
> > > >> 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,
> > >
> On Wed, 2013-12-11 at 17:48 +0100, Jiří Stránský wrote:
>
> > >> 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?
> >
> > p
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
On Wed, 2013-12-11 at 17:48 +0100, Jiří Stránský wrote:
> >> 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-tuskarcl
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 ser
> 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
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 chang
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
> an
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 c
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 comple
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
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 chang
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 t
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 proxyi
On 12/11/2013 01:33 PM, Jiří Stránský wrote:
Hi all,
Hi Jirka,
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
On 12/12/2013 10:49 AM, Jiří Stránský wrote:
On 12.12.2013 09:48, Ladislav Smola wrote:
On 12/11/2013 06:15 PM, Jiří Stránský wrote:
On 11.12.2013 17:13, Ladislav Smola wrote:
Hi,
thanks for starting this conversation.
I will take it little side ways. I think we should be asking why
have we
On 12.12.2013 09:48, Ladislav Smola wrote:
On 12/11/2013 06:15 PM, Jiří Stránský wrote:
On 11.12.2013 17:13, Ladislav Smola wrote:
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 co
On 12/11/2013 05:41 PM, Jay Dobies wrote:
> 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 a
On 12/11/2013 06:15 PM, Jiří Stránský wrote:
On 11.12.2013 17:13, Ladislav Smola wrote:
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)
I'm going to reply to Dean's and James' posts in one shot because it
imho makes most sense.
On 11.12.2013 17:00, Dean Troyer wrote:
On Wed, Dec 11, 2013 at 9:35 AM, James Slagle wrote:
On Wed, Dec 11, 2013 at 7:33 AM, Jiří Stránský wrote:
Previously, we had planned Tuskar arcitecture like t
On 11.12.2013 17:13, Ladislav Smola wrote:
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
t
On Wed, Dec 11, 2013 at 10:41 AM, Jay Dobies wrote:
>
> 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 API bindings and
a t
On 12/11/2013 04:35 PM, James Slagle wrote:
On Wed, Dec 11, 2013 at 7:33 AM, 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 change
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 proxyin
> 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 u
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 association
On Wed, Dec 11, 2013 at 9:35 AM, James Slagle wrote:
> On Wed, Dec 11, 2013 at 7:33 AM, Jiří Stránský wrote:
> > Previously, we had planned Tuskar arcitecture like this:
> >
> > tuskar-ui <-> tuskarclient <-> tuskar-api <-> heat-api|ironic-api|etc.
>
> To be clear, tuskarclient is just a library
On Wed, Dec 11, 2013 at 10:35 AM, James Slagle wrote:
> On Wed, Dec 11, 2013 at 7:33 AM, Jiří Stránský 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, i'm
>> not aware of any python-*c
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 loo
On Wed, Dec 11, 2013 at 7:33 AM, 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 getti
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 mention
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 plan
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 obviou
51 matches
Mail list logo
