3:23 a.m.
----- Original Message -----
On Wed, Jun 8, 2016 at 6:33 PM, Ivan Chavero
<ichavero(a)redhat.com> wrote:
> I can be wrong but right now Packstack can already do this stuff,
> more command line options are needed or it might need little tweaks to the
> code but this is not far from current Packstack options.
Right now Packstack has a lot of code and logic to connect to
additional nodes and do things.
To be honest, the amount of code is not that big (at least to me).
On a quick check over the refactored version, I see
https://github.com/javierpena/packstack/blob/feature/manifest_refactor/pa...
could be simplified (maybe removed), then
https://github.com/javierpena/packstack/blob/feature/manifest_refactor/pa...
would need to be rewritten, to support a single node. Everything else is small
simplifications on the plugins to assume all hosts are the same.
Packstack, itself, connects to compute hosts to install nova, same
with the other kind of hosts.
What I am saying is that Packstack should only ever be able to install
(efficiently) services on "localhost".
Hence, me, as a user (with Ansible or manually), could do something
like I mentioned before:
- Login to Server 1 and run "packstack --install-rabbitmq=y
--install-mariadb=y"
- Login to Server 2 and run "packstack --install-keystone=y
--rabbitmq-server=server1 --database-server=server1"
- Login to Server 3 and run "packstack --install-glance=y
--keystone-server=server2 --database-server=server1
--rabbitmq-server=server1"
- Login to Server 4 and run "packstack --install-nova=y
--keystone-server=server2 --database-server=server1
--rabbitmq-server=server1"
(etc)
This would work, allow multi node without having all the multi node
logic embedded and handled by Packstack itself.
Doing this would require adding a similar layer of complexity, but in the puppet code
instead of python. Right now, we assume that every API service is running on
config['CONTROLLER_HOST'], with your proposal we should have the current host, and
separate variables (and Hiera processing in python) to have a single variable per service.
I think it's a good idea anyway, but I think it wouldn't reduce complexity or any
associated CI coverage concerns.
We could take an easier way and assume we only have 3 roles, as in the current refactored
code: controller, network, compute. The logic would then be:
- By default we install everything, so all in one
- If our host is not CONFIG_CONTROLLER_HOST but is part of CONFIG_NETWORK_HOSTS, we
apply the network manifest
- Same as above if our host is part of CONFIG_COMPUTE_HOSTS
Of course, the last two options would assume a first server is installed as controller.
This would allow us to reuse the same answer file on all runs (one per host as you
proposed), eliminate the ssh code as we are always running locally, and make some
assumptions in the python code, like expecting OPM to be deployed and such. A contributed
ansible wrapper to automate the runs would be straightforward to create.
What do you think? Would it be worth the effort?
Regards,
Javier
David Moreau Simard
Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter]
4:17 a.m.
New subject: [rdo-list] Packstack refactor and future ideas
On Thu, Jun 9, 2016 at 10:23 AM, Javier Pena <javier.pena(a)redhat.com> wrote:
----- Original Message -----
> On Wed, Jun 8, 2016 at 6:33 PM, Ivan Chavero <ichavero(a)redhat.com> wrote:
> > I can be wrong but right now Packstack can already do this stuff,
> > more command line options are needed or it might need little tweaks to the
> > code but this is not far from current Packstack options.
>
> Right now Packstack has a lot of code and logic to connect to
> additional nodes and do things.
To be honest, the amount of code is not that big (at least to me).
On a quick check over the refactored version, I see
https://github.com/javierpena/packstack/blob/feature/manifest_refactor/pa...
could be simplified (maybe removed), then
https://github.com/javierpena/packstack/blob/feature/manifest_refactor/pa...
would need to be rewritten, to support a single node. Everything else is small
simplifications on the plugins to assume all hosts are the same.
> Packstack, itself, connects to compute hosts to install nova, same
> with the other kind of hosts.
>
> What I am saying is that Packstack should only ever be able to install
> (efficiently) services on "localhost".
>
> Hence, me, as a user (with Ansible or manually), could do something
> like I mentioned before:
> - Login to Server 1 and run "packstack --install-rabbitmq=y
> --install-mariadb=y"
> - Login to Server 2 and run "packstack --install-keystone=y
> --rabbitmq-server=server1 --database-server=server1"
> - Login to Server 3 and run "packstack --install-glance=y
> --keystone-server=server2 --database-server=server1
> --rabbitmq-server=server1"
> - Login to Server 4 and run "packstack --install-nova=y
> --keystone-server=server2 --database-server=server1
> --rabbitmq-server=server1"
> (etc)
>
> This would work, allow multi node without having all the multi node
> logic embedded and handled by Packstack itself.
Doing this would require adding a similar layer of complexity, but in the puppet code
instead of python. Right now, we assume that every API service is running on
config['CONTROLLER_HOST'], with your proposal we should have the current host, and
separate variables (and Hiera processing in python) to have a single variable per service.
I think it's a good idea anyway, but I think it wouldn't reduce complexity or any
associated CI coverage concerns.
We could take an easier way and assume we only have 3 roles, as in the current refactored
code: controller, network, compute. The logic would then be:
- By default we install everything, so all in one
- If our host is not CONFIG_CONTROLLER_HOST but is part of CONFIG_NETWORK_HOSTS, we
apply the network manifest
- Same as above if our host is part of CONFIG_COMPUTE_HOSTS
Of course, the last two options would assume a first server is installed as controller.
This would allow us to reuse the same answer file on all runs (one per host as you
proposed), eliminate the ssh code as we are always running locally, and make some
assumptions in the python code, like expecting OPM to be deployed and such. A contributed
ansible wrapper to automate the runs would be straightforward to create.
What do you think? Would it be worth the effort?
IMO, the modular deployment model proposed by David is the best
approach for openstack installers that i always dreamt about when
deploying OpenStack in real production environments. However, i think
moving into that will be hard and would exceed the PoC oriented nature
of Packstack where a controller + compute + network should suffice.
In fact, i'd say that the best way to go for this modular approach is
with containers and a orchestration tool designed for them
(kubernetes, right?) but this is a different story, :)
Regards,
Javier
>
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
>
> dmsimard = [irc, github, twitter]
>
_______________________________________________
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:48 a.m.
New subject: [rdo-list] Packstack refactor and future ideas
In fact, i'd say that the best way to go for this modular
approach is
with containers and a orchestration tool designed for them
(kubernetes, right?) but this is a different story, :)
i agree with you, i've been flirting with the idea of doing that for
a while now
Cheers,
Ivan
6:47 a.m.
New subject: [rdo-list] Packstack refactor and future ideas
We could take an easier way and assume we only have 3 roles, as in
the current refactored code: controller, network, compute. The logic would then be:
- By default we install everything, so all in one
- If our host is not CONFIG_CONTROLLER_HOST but is part of CONFIG_NETWORK_HOSTS, we
apply the network manifest
- Same as above if our host is part of CONFIG_COMPUTE_HOSTS
Of course, the last two options would assume a first server is installed as controller.
This would allow us to reuse the same answer file on all runs (one per host as you
proposed), eliminate the ssh code as we are always running locally, and make some
assumptions in the python code, like expecting OPM to be deployed and such. A contributed
ansible wrapper to automate the runs would be straightforward to create.
What do you think? Would it be worth the effort?
+2 I like that proposal a lot! An ansible wrapper is then just an
example playbook in docs but could be done w/o ansible as well,
manually or using some other remote execution tooling of user's
choice.
Alan
9:45 a.m.
New subject: [rdo-list] Packstack refactor and future ideas
----- Original Message -----
> We could take an easier way and assume we only have 3 roles, as
in the
> current refactored code: controller, network, compute. The logic would
> then be:
> - By default we install everything, so all in one
> - If our host is not CONFIG_CONTROLLER_HOST but is part of
> CONFIG_NETWORK_HOSTS, we apply the network manifest
> - Same as above if our host is part of CONFIG_COMPUTE_HOSTS
>
> Of course, the last two options would assume a first server is installed as
> controller.
>
> This would allow us to reuse the same answer file on all runs (one per host
> as you proposed), eliminate the ssh code as we are always running locally,
> and make some assumptions in the python code, like expecting OPM to be
> deployed and such. A contributed ansible wrapper to automate the runs
> would be straightforward to create.
>
> What do you think? Would it be worth the effort?
+2 I like that proposal a lot! An ansible wrapper is then just an
example playbook in docs but could be done w/o ansible as well,
manually or using some other remote execution tooling of user's
choice.
Now that the phase 1 refactor is under review and passing CI, I think it's time to
come to a conclusion on this.
This option looks like the best compromise between keeping it simple and dropping the
least possible amount of features. So unless someone has a better idea, I'll work on
that as soon as the current review is merged.
Regards,
Javier
Alan
10:15 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 Javier
Pena <javier.pena(a)redhat.com>
Sent: Friday, June 17, 2016 10:45 AM
To: rdo-list
Cc: alan pevec
Subject: Re: [rdo-list] Packstack refactor and future ideas
----- Original Message -----
> We could take an easier way and assume we only have 3 roles, as
in the
> current refactored code: controller, network, compute. The logic would
> then be:
> - By default we install everything, so all in one
> - If our host is not CONFIG_CONTROLLER_HOST but is part of
> CONFIG_NETWORK_HOSTS, we apply the network manifest
> - Same as above if our host is part of CONFIG_COMPUTE_HOSTS
>
> Of course, the last two options would assume a first server is installed as
> controller.
>
> This would allow us to reuse the same answer file on all runs (one per host
> as you proposed), eliminate the ssh code as we are always running locally,
> and make some assumptions in the python code, like expecting OPM to be
> deployed and such. A contributed ansible wrapper to automate the runs
> would be straightforward to create.
>
> What do you think? Would it be worth the effort?
+2 I like that proposal a lot! An ansible wrapper is then just an
example playbook in docs but could be done w/o ansible as well,
manually or using some other remote execution tooling of user's
choice.
Now that the phase 1 refactor is under review and passing CI, I think it's time to
come to a conclusion on this.
This option looks like the best compromise between keeping it simple and dropping the
least possible amount of features. So unless someone has a better idea, I'll work on
that as soon as the current review is merged.
Would it be possible :-
- By default we install everything, so all in one
- If our host is not CONFIG_CONTROLLER_HOST but is part of
CONFIG_NETWORK_HOSTS, we apply the network manifest
- Same as above if our host is part of CONFIG_COMPUTE_HOSTS
- If our host is not CONFIG_CONTROLLER_HOST but is part of
CONFIG_STORAGE_HOSTS, we apply the storage manifest
Just one more role. May we have 4 roles ?
Thanks
Boris.
Regards,
Javier
Alan
_______________________________________________
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
6:44 a.m.
New subject: [rdo-list] Packstack refactor and future ideas
----- Original Message -----
From: rdo-list-bounces(a)redhat.com <rdo-list-bounces(a)redhat.com>
on behalf of
Javier Pena <javier.pena(a)redhat.com>
Sent: Friday, June 17, 2016 10:45 AM
To: rdo-list
Cc: alan pevec
Subject: Re: [rdo-list] Packstack refactor and future ideas
----- Original Message -----
> > We could take an easier way and assume we only have 3 roles, as in the
> > current refactored code: controller, network, compute. The logic would
> > then be:
> > - By default we install everything, so all in one
> > - If our host is not CONFIG_CONTROLLER_HOST but is part of
> > CONFIG_NETWORK_HOSTS, we apply the network manifest
> > - Same as above if our host is part of CONFIG_COMPUTE_HOSTS
> >
> > Of course, the last two options would assume a first server is installed
> > as
> > controller.
> >
> > This would allow us to reuse the same answer file on all runs (one per
> > host
> > as you proposed), eliminate the ssh code as we are always running
> > locally,
> > and make some assumptions in the python code, like expecting OPM to be
> > deployed and such. A contributed ansible wrapper to automate the runs
> > would be straightforward to create.
> >
> > What do you think? Would it be worth the effort?
>
> +2 I like that proposal a lot! An ansible wrapper is then just an
> example playbook in docs but could be done w/o ansible as well,
> manually or using some other remote execution tooling of user's
> choice.
>
Now that the phase 1 refactor is under review and passing CI, I think it's
time to come to a conclusion on this.
This option looks like the best compromise between keeping it simple and
dropping the least possible amount of features. So unless someone has a
better idea, I'll work on that as soon as the current review is merged.
Would it be possible :-
- By default we install everything, so all in one
- If our host is not CONFIG_CONTROLLER_HOST but is part of
CONFIG_NETWORK_HOSTS, we apply the network manifest
- Same as above if our host is part of CONFIG_COMPUTE_HOSTS
- If our host is not CONFIG_CONTROLLER_HOST but is part of
CONFIG_STORAGE_HOSTS , we apply the storage manifest
Just one more role. May we have 4 roles ?
This is a tricky one. There used to be support for separate CONFIG_STORAGE_HOSTS, but I
think it has been removed (or at least not tested for quite a long time).
This would need to be a follow-up review, if it is finally decided to do so.
Regards,
Javier
Thanks
Boris.
Regards,
Javier
> Alan
>
_______________________________________________
rdo-list mailing list
rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
rdo-list Info Page - Red Hat
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
8:35 a.m.
New subject: [rdo-list] Packstack refactor and future ideas
________________________________
From: Javier Pena <javier.pena(a)redhat.com>
Sent: Monday, June 20, 2016 7:44 AM
To: Boris Derzhavets
Cc: rdo-list; alan pevec
Subject: Re: [rdo-list] Packstack refactor and future ideas
----- Original Message -----
From: rdo-list-bounces(a)redhat.com <rdo-list-bounces(a)redhat.com>
on behalf of
Javier Pena <javier.pena(a)redhat.com>
Sent: Friday, June 17, 2016 10:45 AM
To: rdo-list
Cc: alan pevec
Subject: Re: [rdo-list] Packstack refactor and future ideas
----- Original Message -----
> > We could take an easier way and assume we only have 3 roles, as in the
> > current refactored code: controller, network, compute. The logic would
> > then be:
> > - By default we install everything, so all in one
> > - If our host is not CONFIG_CONTROLLER_HOST but is part of
> > CONFIG_NETWORK_HOSTS, we apply the network manifest
> > - Same as above if our host is part of CONFIG_COMPUTE_HOSTS
> >
> > Of course, the last two options would assume a first server is installed
> > as
> > controller.
> >
> > This would allow us to reuse the same answer file on all runs (one per
> > host
> > as you proposed), eliminate the ssh code as we are always running
> > locally,
> > and make some assumptions in the python code, like expecting OPM to be
> > deployed and such. A contributed ansible wrapper to automate the runs
> > would be straightforward to create.
> >
> > What do you think? Would it be worth the effort?
>
> +2 I like that proposal a lot! An ansible wrapper is then just an
> example playbook in docs but could be done w/o ansible as well,
> manually or using some other remote execution tooling of user's
> choice.
>
Now that the phase 1 refactor is under review and passing CI, I think it's
time to come to a conclusion on this.
This option looks like the best compromise between keeping it simple and
dropping the least possible amount of features. So unless someone has a
better idea, I'll work on that as soon as the current review is merged.
Would it be possible :-
- By default we install everything, so all in one
- If our host is not CONFIG_CONTROLLER_HOST but is part of
CONFIG_NETWORK_HOSTS, we apply the network manifest
- Same as above if our host is part of CONFIG_COMPUTE_HOSTS
- If our host is not CONFIG_CONTROLLER_HOST but is part of
CONFIG_STORAGE_HOSTS , we apply the storage manifest
Just one more role. May we have 4 roles ?
This is a tricky one. There used to be support for separate CONFIG_STORAGE_HOSTS, but I
think it has been removed (or at least not tested for quite a long time).
However, this feature currently works for RDO Mitaka ( as well it woks for Liberty)
It's even possible to add Storage Node via packstack , taking care of glance and
swift proxy
keystone endpoints manually .
For small prod deployments like several (5-10) Haswell Xeon boxes. ( no HA
requirements from
customer's side ). Ability to split Storage specifically Swift (AIO) instances or
Cinder iSCSILVM
back ends hosting Node from Controller is extremely critical feature.
What I am writing is based on several projects committed in South America's
countries.
No complaints from site support stuff to myself for configurations deployed via
Packstack.
Dropping this feature ( unsupported , but stable working ) will for sure make
Packstack
almost useless toy .
In situation when I am able only play with TripleO QuickStart due to Upstream
docs
( Mitaka trunk instructions set) for instack-virt-setup don't allow to commit
`openstack undercloud install` makes Howto :-
https://remote-lab.net/rdo-manager-ha-openstack-deployment
<https://remote-lab.net/rdo-manager-ha-openstack-deployment> non reproducible. I
have nothing against TripleO turn, but absence of Red Hat
high quality manuals for TripleO bare metal / TripleO Instak-virt-setup
will affect RDO Community in wide spread way. I mean first all countries
like Chile, Brazil, China and etc.
Thank you.
Boris.
This would need to be a follow-up review, if it is finally decided to do so.
Regards,
Javier
Thanks
Boris.
Regards,
Javier
> Alan
>
_______________________________________________
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 ...
rdo-list Info Page - Red Hat
www.redhat.com<http://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
9:11 a.m.
New subject: [rdo-list] Packstack refactor and future ideas
----- Original Message -----
From: "Boris Derzhavets" <bderzhavets(a)hotmail.com>
To: "Javier Pena" <javier.pena(a)redhat.com>
Cc: "alan pevec" <alan.pevec(a)redhat.com>, "rdo-list"
<rdo-list(a)redhat.com>
Sent: Monday, June 20, 2016 8:35:52 AM
Subject: Re: [rdo-list] Packstack refactor and future ideas
From: Javier Pena <javier.pena(a)redhat.com>
Sent: Monday, June 20, 2016 7:44 AM
To: Boris Derzhavets
Cc: rdo-list; alan pevec
Subject: Re: [rdo-list] Packstack refactor and future ideas
----- Original Message -----
> From: rdo-list-bounces(a)redhat.com <rdo-list-bounces(a)redhat.com> on behalf
> of
> Javier Pena <javier.pena(a)redhat.com>
> Sent: Friday, June 17, 2016 10:45 AM
> To: rdo-list
> Cc: alan pevec
> Subject: Re: [rdo-list] Packstack refactor and future ideas
> ----- Original Message -----
> > > We could take an easier way and assume we only have 3 roles, as in the
> > > current refactored code: controller, network, compute. The logic would
> > > then be:
> > > - By default we install everything, so all in one
> > > - If our host is not CONFIG_CONTROLLER_HOST but is part of
> > > CONFIG_NETWORK_HOSTS, we apply the network manifest
> > > - Same as above if our host is part of CONFIG_COMPUTE_HOSTS
> > >
> > > Of course, the last two options would assume a first server is
> > > installed
> > > as
> > > controller.
> > >
> > > This would allow us to reuse the same answer file on all runs (one per
> > > host
> > > as you proposed), eliminate the ssh code as we are always running
> > > locally,
> > > and make some assumptions in the python code, like expecting OPM to be
> > > deployed and such. A contributed ansible wrapper to automate the runs
> > > would be straightforward to create.
> > >
> > > What do you think? Would it be worth the effort?
> >
> > +2 I like that proposal a lot! An ansible wrapper is then just an
> > example playbook in docs but could be done w/o ansible as well,
> > manually or using some other remote execution tooling of user's
> > choice.
> >
> Now that the phase 1 refactor is under review and passing CI, I think it's
> time to come to a conclusion on this.
> This option looks like the best compromise between keeping it simple and
> dropping the least possible amount of features. So unless someone has a
> better idea, I'll work on that as soon as the current review is merged.
>
> Would it be possible :-
>
> - By default we install everything, so all in one
> - If our host is not CONFIG_CONTROLLER_HOST but is part of
> CONFIG_NETWORK_HOSTS, we apply the network manifest
> - Same as above if our host is part of CONFIG_COMPUTE_HOSTS
> - If our host is not CONFIG_CONTROLLER_HOST but is part of
> CONFIG_STORAGE_HOSTS , we apply the storage manifest
>
> Just one more role. May we have 4 roles ?
This is a tricky one. There used to be support for separate
CONFIG_STORAGE_HOSTS, but I think it has been removed (or at least not
tested for quite a long time).
This option is still there, is set as "unsupported" i think it might be
a good idea to keep it.
what do you guys think?
However, this feature currently works for RDO Mitaka ( as well it
woks for
Liberty)
It's even possible to add Storage Node via packstack , taking care of glance
and swift proxy
keystone endpoints manually .
For small prod deployments like several (5-10) Haswell Xeon boxes. ( no HA
requirements from
customer's side ). Ability to split Storage specifically Swift (AIO)
instances or Cinder iSCSILVM
back ends hosting Node from Controller is extremely critical feature.
What I am writing is based on several projects committed in South America's
countries.
No complaints from site support stuff to myself for configurations deployed
via Packstack.
Dropping this feature ( unsupported , but stable working ) will for sure make
Packstack
almost useless toy .
In situation when I am able only play with TripleO QuickStart due to Upstream
docs
( Mitaka trunk instructions set) for instack-virt-setup don't allow to commit
`openstack undercloud install` makes Howto :-
https://remote-lab.net/rdo-manager-ha-openstack-deployment
non reproducible. I have nothing against TripleO turn, but absence of Red Hat
high quality manuals for TripleO bare metal / TripleO Instak-virt-setup
will affect RDO Community in wide spread way. I mean first all countries
like Chile, Brazil, China and etc.
Thank you.
Boris.
This would need to be a follow-up review, if it is finally decided to do so.
Regards,
Javier
> Thanks
> Boris.
> Regards,
> Javier
> > Alan
> >
> _______________________________________________
> rdo-list mailing list
> rdo-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
rdo-list Info Page - Red Hat
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 ...
> rdo-list Info Page - Red Hat
> 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
_______________________________________________
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
10:18 a.m.
New subject: [rdo-list] Packstack refactor and future ideas
Having a tiny, multi-node, non-HA cloud has been extremely useful for
developing anything that needs an Openstack cloud to talk to.
We don't care if the cloud dies. Our VM images and recipes are elsewhere.
We rebuild the clouds as needed. We migrate to another working cloud while
we rebuild if needed.
We need to test > 1 compute node but not 5 compute nodes. Ex: migration
can't be done on a single node!
packstack is ideal. A 2 node cloud where both nodes need to do compute
lets us run 20-30 VMs to test. We also need multiple clouds.
We have "production" clouds and need a minimum of 3 nodes == 50% more costs
and the controller is mostly idle. Going from 1 to 5 (7?) for a "real
production" cloud is a big leap.
We don't need HA and the load on the controller is light enough that it can
also handle compute.
On Mon, Jun 20, 2016 at 10:11 AM, Ivan Chavero <ichavero(a)redhat.com> wrote:
----- Original Message -----
> From: "Boris Derzhavets" <bderzhavets(a)hotmail.com>
> To: "Javier Pena" <javier.pena(a)redhat.com>
> Cc: "alan pevec" <alan.pevec(a)redhat.com>, "rdo-list" <
rdo-list(a)redhat.com>
> Sent: Monday, June 20, 2016 8:35:52 AM
> Subject: Re: [rdo-list] Packstack refactor and future ideas
>
>
>
>
>
>
>
> From: Javier Pena <javier.pena(a)redhat.com>
> Sent: Monday, June 20, 2016 7:44 AM
> To: Boris Derzhavets
> Cc: rdo-list; alan pevec
> Subject: Re: [rdo-list] Packstack refactor and future ideas
> ----- Original Message -----
>
> > From: rdo-list-bounces(a)redhat.com <rdo-list-bounces(a)redhat.com> on
behalf
> > of
> > Javier Pena <javier.pena(a)redhat.com>
> > Sent: Friday, June 17, 2016 10:45 AM
> > To: rdo-list
> > Cc: alan pevec
> > Subject: Re: [rdo-list] Packstack refactor and future ideas
>
> > ----- Original Message -----
> > > > We could take an easier way and assume we only have 3 roles, as in
the
> > > > current refactored code: controller, network, compute. The logic
would
> > > > then be:
> > > > - By default we install everything, so all in one
> > > > - If our host is not CONFIG_CONTROLLER_HOST but is part of
> > > > CONFIG_NETWORK_HOSTS, we apply the network manifest
> > > > - Same as above if our host is part of CONFIG_COMPUTE_HOSTS
> > > >
> > > > Of course, the last two options would assume a first server is
> > > > installed
> > > > as
> > > > controller.
> > > >
> > > > This would allow us to reuse the same answer file on all runs (one
per
> > > > host
> > > > as you proposed), eliminate the ssh code as we are always running
> > > > locally,
> > > > and make some assumptions in the python code, like expecting OPM
to be
> > > > deployed and such. A contributed ansible wrapper to automate the
runs
> > > > would be straightforward to create.
> > > >
> > > > What do you think? Would it be worth the effort?
> > >
> > > +2 I like that proposal a lot! An ansible wrapper is then just an
> > > example playbook in docs but could be done w/o ansible as well,
> > > manually or using some other remote execution tooling of user's
> > > choice.
> > >
> > Now that the phase 1 refactor is under review and passing CI, I think
it's
> > time to come to a conclusion on this.
> > This option looks like the best compromise between keeping it simple
and
> > dropping the least possible amount of features. So unless someone has a
> > better idea, I'll work on that as soon as the current review is merged.
> >
> > Would it be possible :-
> >
> > - By default we install everything, so all in one
> > - If our host is not CONFIG_CONTROLLER_HOST but is part of
> > CONFIG_NETWORK_HOSTS, we apply the network manifest
> > - Same as above if our host is part of CONFIG_COMPUTE_HOSTS
> > - If our host is not CONFIG_CONTROLLER_HOST but is part of
> > CONFIG_STORAGE_HOSTS , we apply the storage manifest
> >
> > Just one more role. May we have 4 roles ?
>
> This is a tricky one. There used to be support for separate
> CONFIG_STORAGE_HOSTS, but I think it has been removed (or at least not
> tested for quite a long time).
This option is still there, is set as "unsupported" i think it might be
a good idea to keep it.
what do you guys think?
> However, this feature currently works for RDO Mitaka ( as well it woks
for
> Liberty)
> It's even possible to add Storage Node via packstack , taking care of
glance
> and swift proxy
> keystone endpoints manually .
> For small prod deployments like several (5-10) Haswell Xeon boxes. ( no
HA
> requirements from
> customer's side ). Ability to split Storage specifically Swift (AIO)
> instances or Cinder iSCSILVM
> back ends hosting Node from Controller is extremely critical feature.
> What I am writing is based on several projects committed in South
America's
> countries.
> No complaints from site support stuff to myself for configurations
deployed
> via Packstack.
> Dropping this feature ( unsupported , but stable working ) will for sure
make
> Packstack
> almost useless toy .
> In situation when I am able only play with TripleO QuickStart due to
Upstream
> docs
> ( Mitaka trunk instructions set) for instack-virt-setup don't allow to
commit
> `openstack undercloud install` makes Howto :-
>
> https://remote-lab.net/rdo-manager-ha-openstack-deployment
>
> non reproducible. I have nothing against TripleO turn, but absence of
Red Hat
> high quality manuals for TripleO bare metal / TripleO Instak-virt-setup
> will affect RDO Community in wide spread way. I mean first all countries
> like Chile, Brazil, China and etc.
>
> Thank you.
> Boris.
>
> This would need to be a follow-up review, if it is finally decided to do
so.
>
> Regards,
> Javier
>
> > Thanks
> > Boris.
>
> > Regards,
> > Javier
>
> > > Alan
> > >
>
> > _______________________________________________
> > rdo-list mailing list
> > rdo-list(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/rdo-list
>
>
> rdo-list Info Page - Red Hat
> 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 ...
>
>
> > rdo-list Info Page - Red Hat
> > 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
>
> _______________________________________________
> 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
_______________________________________________
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
11:51 a.m.
New subject: [rdo-list] Packstack refactor and future ideas
________________________________
From: tbuskey(a)gmail.com <tbuskey(a)gmail.com> on behalf of Tom Buskey
<tom(a)buskey.name>
Sent: Wednesday, June 22, 2016 11:18 AM
To: Ivan Chavero
Cc: Boris Derzhavets; alan pevec; rdo-list; Javier Pena
Subject: Re: [rdo-list] Packstack refactor and future ideas
Having a tiny, multi-node, non-HA cloud has been extremely useful for developing anything
that needs an Openstack cloud to talk to.
We don't care if the cloud dies. Our VM images and recipes are elsewhere. We rebuild
the clouds as needed. We migrate to another working cloud while we rebuild if needed.
We need to test > 1 compute node but not 5 compute nodes. Ex: migration can't be
done on a single node!
packstack is ideal. A 2 node cloud where both nodes need to do compute lets us run 20-30
VMs to test. We also need multiple clouds.
In current thread there were 2 major arguments why packstack has to be dropped ( or at
least less functional
in regards of multinode support then currently in RDO Mitaka )
1. Multinode functionality cannot pass CI ( creating this tests is out of scope
, hence it should be dropped)
If it is not tested , then it is not working BY DEFINITION ( I am quoting
Alan word in word )
Why Lars Kellogg-Stedman provided "RDO Havana Hangout" via
YouTube and as slide-show,
he was explaining packstack functionality which NEVER passed CI ?
Something happened in Mitaka/Newton times - TripleO stabilized ( first of
all on bare metal )
2. Packstack is compromising RDO providing to customers wrong impression about
RDO Core features
in reality and in meantime . Hence, it is breaking correct focus on
Triple0 Bare Betal/TripleO QuickStart
( now virtual but supposed to handle bare metal ASAP) .
Regarding statement (2) I would better hold my opinion with myself.
Boris.
We have "production" clouds and need a minimum of 3 nodes == 50% more costs and
the controller is mostly idle. Going from 1 to 5 (7?) for a "real production"
cloud is a big leap.
We don't need HA and the load on the controller is light enough that it can also
handle compute.
On Mon, Jun 20, 2016 at 10:11 AM, Ivan Chavero
<ichavero@redhat.com<mailto:ichavero@redhat.com>> wrote:
----- Original Message -----
From: "Boris Derzhavets"
<bderzhavets@hotmail.com<mailto:bderzhavets@hotmail.com>>
To: "Javier Pena"
<javier.pena@redhat.com<mailto:javier.pena@redhat.com>>
Cc: "alan pevec"
<alan.pevec@redhat.com<mailto:alan.pevec@redhat.com>>, "rdo-list"
<rdo-list@redhat.com<mailto:rdo-list@redhat.com>>
Sent: Monday, June 20, 2016 8:35:52 AM
Subject: Re: [rdo-list] Packstack refactor and future ideas
From: Javier Pena <javier.pena@redhat.com<mailto:javier.pena@redhat.com>>
Sent: Monday, June 20, 2016 7:44 AM
To: Boris Derzhavets
Cc: rdo-list; alan pevec
Subject: Re: [rdo-list] Packstack refactor and future ideas
----- Original Message -----
> From: rdo-list-bounces@redhat.com<mailto:rdo-list-bounces@redhat.com>
<rdo-list-bounces@redhat.com<mailto:rdo-list-bounces@redhat.com>> on behalf
> of
> Javier Pena <javier.pena@redhat.com<mailto:javier.pena@redhat.com>>
> Sent: Friday, June 17, 2016 10:45 AM
> To: rdo-list
> Cc: alan pevec
> Subject: Re: [rdo-list] Packstack refactor and future ideas
> ----- Original Message -----
> > > We could take an easier way and assume we only have 3 roles, as in the
> > > current refactored code: controller, network, compute. The logic would
> > > then be:
> > > - By default we install everything, so all in one
> > > - If our host is not CONFIG_CONTROLLER_HOST but is part of
> > > CONFIG_NETWORK_HOSTS, we apply the network manifest
> > > - Same as above if our host is part of CONFIG_COMPUTE_HOSTS
> > >
> > > Of course, the last two options would assume a first server is
> > > installed
> > > as
> > > controller.
> > >
> > > This would allow us to reuse the same answer file on all runs (one per
> > > host
> > > as you proposed), eliminate the ssh code as we are always running
> > > locally,
> > > and make some assumptions in the python code, like expecting OPM to be
> > > deployed and such. A contributed ansible wrapper to automate the runs
> > > would be straightforward to create.
> > >
> > > What do you think? Would it be worth the effort?
> >
> > +2 I like that proposal a lot! An ansible wrapper is then just an
> > example playbook in docs but could be done w/o ansible as well,
> > manually or using some other remote execution tooling of user's
> > choice.
> >
> Now that the phase 1 refactor is under review and passing CI, I think it's
> time to come to a conclusion on this.
> This option looks like the best compromise between keeping it simple and
> dropping the least possible amount of features. So unless someone has a
> better idea, I'll work on that as soon as the current review is merged.
>
> Would it be possible :-
>
> - By default we install everything, so all in one
> - If our host is not CONFIG_CONTROLLER_HOST but is part of
> CONFIG_NETWORK_HOSTS, we apply the network manifest
> - Same as above if our host is part of CONFIG_COMPUTE_HOSTS
> - If our host is not CONFIG_CONTROLLER_HOST but is part of
> CONFIG_STORAGE_HOSTS , we apply the storage manifest
>
> Just one more role. May we have 4 roles ?
This is a tricky one. There used to be support for separate
CONFIG_STORAGE_HOSTS, but I think it has been removed (or at least not
tested for quite a long time).
This option is still there, is set as "unsupported" i think it might be
a good idea to keep it.
what do you guys think?
However, this feature currently works for RDO Mitaka ( as well it
woks for
Liberty)
It's even possible to add Storage Node via packstack , taking care of glance
and swift proxy
keystone endpoints manually .
For small prod deployments like several (5-10) Haswell Xeon boxes. ( no HA
requirements from
customer's side ). Ability to split Storage specifically Swift (AIO)
instances or Cinder iSCSILVM
back ends hosting Node from Controller is extremely critical feature.
What I am writing is based on several projects committed in South America's
countries.
No complaints from site support stuff to myself for configurations deployed
via Packstack.
Dropping this feature ( unsupported , but stable working ) will for sure make
Packstack
almost useless toy .
In situation when I am able only play with TripleO QuickStart due to Upstream
docs
( Mitaka trunk instructions set) for instack-virt-setup don't allow to commit
`openstack undercloud install` makes Howto :-
https://remote-lab.net/rdo-manager-ha-openstack-deployment
non reproducible. I have nothing against TripleO turn, but absence of Red Hat
high quality manuals for TripleO bare metal / TripleO Instak-virt-setup
will affect RDO Community in wide spread way. I mean first all countries
like Chile, Brazil, China and etc.
Thank you.
Boris.
This would need to be a follow-up review, if it is finally decided to do so.
Regards,
Javier
> Thanks
> Boris.
> Regards,
> Javier
> > Alan
> >
> _______________________________________________
> rdo-list mailing list
> rdo-list@redhat.com<mailto:rdo-list@redhat.com>
> https://www.redhat.com/mailman/listinfo/rdo-list
rdo-list Info Page - Red Hat
www.redhat.com<http://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 ...
> rdo-list Info Page - Red Hat
> www.redhat.com<http://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@redhat.com<mailto:rdo-list-unsubscribe@redhat.com>
> _______________________________________________
> rdo-list mailing list
> rdo-list@redhat.com<mailto:rdo-list@redhat.com>
> https://www.redhat.com/mailman/listinfo/rdo-list
> To unsubscribe:
rdo-list-unsubscribe@redhat.com<mailto:rdo-list-unsubscribe@redhat.com>
_______________________________________________
rdo-list mailing list
rdo-list@redhat.com<mailto:rdo-list@redhat.com>
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe:
rdo-list-unsubscribe@redhat.com<mailto:rdo-list-unsubscribe@redhat.com>
_______________________________________________
rdo-list mailing list
rdo-list@redhat.com<mailto:rdo-list@redhat.com>
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe:
rdo-list-unsubscribe@redhat.com<mailto:rdo-list-unsubscribe@redhat.com>
3074
days inactive
3087
days old
10 comments
6 participants
participants (6)
-
Alan Pevec -
Alfredo Moralejo Alonso -
Boris Derzhavets -
Ivan Chavero -
Javier Pena -
Tom Buskey