6:05 p.m.
----- Original Message -----
From: "Alan Pevec" <apevec(a)redhat.com>
To: "Ivan Chavero" <ichavero(a)redhat.com>
Cc: "rdo-list" <rdo-list(a)redhat.com>
Sent: Wednesday, June 8, 2016 5:48:07 PM
Subject: Re: [rdo-list] Packstack refactor and future ideas
> I don't agree with this, we can set the untested features as
"experimental"
or "unsupported"
Best is to remove them to make that clear, because no matter what
deprecation warnings you put[*] people will keep using features until
they're gone, giving us bug reports to take care of and without CI to
verify fixes.
It's long-term maintenance burden I am concerned about, for features
which are clearly out of scope.
I understand this, my concern is that if we remove this feature we will leave
users with no tool for doing multinode in a lightweight way and this might
drive off users from testing/adopting RDO.
I'm willing to create CI tests for multinode Packstack in order to maintain
this features.
And believe me it would be easier for me just to drop this features but i really
think users are benefiting from this features.
Cheers,
Ivan
6:21 p.m.
New subject: [rdo-list] Packstack refactor and future ideas
I understand this, my concern is that if we remove this feature we
will leave
users with no tool for doing multinode in a lightweight way and this might
drive off users from testing/adopting RDO.
We would provide equivalent tool based on singlenode Packstack, with a
clear unsupported message.
That's really the only honest and responsible thing we can do, given
resources available.
I'm willing to create CI tests for multinode Packstack in order
to maintain
this features.
It's not just tests, it's multinode CI infra that is hard.
Cheers,
Alan
4:07 a.m.
New subject: [rdo-list] Packstack refactor and future ideas
On Thu, Jun 9, 2016 at 1:21 AM, Alan Pevec <apevec(a)redhat.com> wrote:
> I understand this, my concern is that if we remove this feature
we will leave
> users with no tool for doing multinode in a lightweight way and this might
> drive off users from testing/adopting RDO.
We would provide equivalent tool based on singlenode Packstack, with a
clear unsupported message.
That's really the only honest and responsible thing we can do, given
resources available.
Given that:
- Users require multihost for PoCs
- We can't test multihost in CI
What is the difference between creating a new "unsupported" additional
tool and marking multihost capabilities in packstack as
"unsuported/untested"?.
Current code enabling multihost in packstack is working and i have
doubts about the expected wins in time supporting multihost in
packstack versus creating a new ansible tooling and modifying
packstack to work fine in this new "externally orchestrated mode".
> I'm willing to create CI tests for multinode Packstack in
order to maintain
> this features.
It's not just tests, it's multinode CI infra that is hard.
Cheers,
Alan
_______________________________________________
rdo-list mailing list
rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe(a)redhat.com
6:44 a.m.
New subject: [rdo-list] Packstack refactor and future ideas
What is the difference between creating a new "unsupported"
additional
tool and marking multihost capabilities in packstack as
"unsuported/untested"?.
Looks like one of my reply didn't reach rdo-list (I got
<rdo-list@redhat.com>... User unknown ??)
Difference is that no matter what deprecation warnings you put people
will keep using features until they're really gone and those features
are out of scope.
Current code enabling multihost in packstack is working and i have
It still adds complexity vs assuming local execution i.e. now
Packstack does ssh even to localhost, right?
doubts about the expected wins in time supporting multihost in
packstack versus creating a new ansible tooling and modifying
packstack to work fine in this new "externally orchestrated mode".
Win is the clear focus for the tool and local execution without
messing with ssh.
I like Javier's proposal that would keep controller, network, compute
then you just need to execute packstack on multiple machines with the
same answer file, manually or using Ansible.
In that case, "new ansible tooling" is really just an example playbook in
docs/.
Cheers,
Alan
9:12 a.m.
New subject: [rdo-list] Packstack refactor and future ideas
On 06/08/2016 07:05 PM, Ivan Chavero wrote:
----- Original Message -----
> From: "Alan Pevec" <apevec(a)redhat.com>
> To: "Ivan Chavero" <ichavero(a)redhat.com>
> Cc: "rdo-list" <rdo-list(a)redhat.com>
> Sent: Wednesday, June 8, 2016 5:48:07 PM
> Subject: Re: [rdo-list] Packstack refactor and future ideas
>
>> I don't agree with this, we can set the untested features as
"experimental"
> or "unsupported"
>
> Best is to remove them to make that clear, because no matter what
> deprecation warnings you put[*] people will keep using features until
> they're gone, giving us bug reports to take care of and without CI to
> verify fixes.
> It's long-term maintenance burden I am concerned about, for features
> which are clearly out of scope.
I understand this, my concern is that if we remove this feature we will leave
users with no tool for doing multinode in a lightweight way and this might
drive off users from testing/adopting RDO.
I think it is starting to have the opposite effect. Packstack, being
available, gives the wrong idea about RDO: you are supposed to install
bare metal.
The Tripleo Quickstart approach is that everything is in a VM.
Packstack is doing too much: image building, provision, and running the
system.
A better approach would be to have our tooling set out so that a user
can build their own images, and then deploy to a VM. OR better yet, a
container.
We need to drive on to Kolla.
Kolla as the Controller for Tripleo and Kolla running in a VM and Kolla
running on my desktop should all be close enough to identical to avoid
the fragmentation we have now.
I'm willing to create CI tests for multinode Packstack in order to maintain
this features.
And believe me it would be easier for me just to drop this features but i really
think users are benefiting from this features.
Cheers,
Ivan
_______________________________________________
rdo-list mailing list
rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe(a)redhat.com
9:42 a.m.
New subject: [rdo-list] Packstack refactor and future ideas
________________________________
From: rdo-list-bounces(a)redhat.com <rdo-list-bounces(a)redhat.com> on behalf of Adam
Young <ayoung(a)redhat.com>
Sent: Thursday, June 9, 2016 10:12 AM
To: rdo-list(a)redhat.com
Subject: Re: [rdo-list] Packstack refactor and future ideas
On 06/08/2016 07:05 PM, Ivan Chavero wrote:
----- Original Message -----
> From: "Alan Pevec" <apevec(a)redhat.com>
> To: "Ivan Chavero" <ichavero(a)redhat.com>
> Cc: "rdo-list" <rdo-list(a)redhat.com>
> Sent: Wednesday, June 8, 2016 5:48:07 PM
> Subject: Re: [rdo-list] Packstack refactor and future ideas
>
>> I don't agree with this, we can set the untested features as
"experimental"
> or "unsupported"
>
> Best is to remove them to make that clear, because no matter what
> deprecation warnings you put[*] people will keep using features until
> they're gone, giving us bug reports to take care of and without CI to
> verify fixes.
> It's long-term maintenance burden I am concerned about, for features
> which are clearly out of scope.
I understand this, my concern is that if we remove this feature we will leave
users with no tool for doing multinode in a lightweight way and this might
drive off users from testing/adopting RDO.
I think it is starting to have the opposite effect. Packstack, being
available, gives the wrong idea about RDO: you are supposed to install
bare metal.
The Tripleo Quickstart approach is that everything is in a VM.
Sorry , if I am asking stupid question , but in meantime TripleO QuickStart
configuration been generated on VIRTHOST is not persistent between cold
reboots. As soon as I shutdown UNDERCLOUD VM (as stack) it's gone for ever.
Packstack deployments on usual VMs driven by KVM/Libvirt are persistent
between cold reboots. I don't have to start every morning from scratch
Am I missing something in current TripleO QuickStart status ?
Thanks.
Boris.
Packstack is doing too much: image building, provision, and running the
system.
A better approach would be to have our tooling set out so that a user
can build their own images, and then deploy to a VM. OR better yet, a
container.
We need to drive on to Kolla.
Kolla as the Controller for Tripleo and Kolla running in a VM and Kolla
running on my desktop should all be close enough to identical to avoid
the fragmentation we have now.
I'm willing to create CI tests for multinode Packstack in order to maintain
this features.
And believe me it would be easier for me just to drop this features but i really
think users are benefiting from this features.
Cheers,
Ivan
_______________________________________________
rdo-list mailing list
rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
rdo-list Info Page - Red
Hat<https://www.redhat.com/mailman/listinfo/rdo-list>
www.redhat.com
The rdo-list mailing list provides a forum for discussions about installing, running, and
using OpenStack on Red Hat based distributions. To see the collection of ...
To unsubscribe: rdo-list-unsubscribe(a)redhat.com
_______________________________________________
rdo-list mailing list
rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe(a)redhat.com
3087
days inactive
3088
days old
5 comments
5 participants
participants (5)
-
Adam Young -
Alan Pevec -
Alfredo Moralejo Alonso -
Boris Derzhavets -
Ivan Chavero