Re: [openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes

2018-07-20 Thread Ben Nemec 



On 07/20/2018 02:06 PM, Emilien Macchi wrote:



On Fri, Jul 20, 2018 at 2:55 PM Ben Nemec > wrote:


Okay, based on a private conversation this is coming off as way more
troll-ish than I intended.  I don't understand where this work is
going,
but I don't really need to so I'll step back from the discussion.
Apologies for any offense.


No offense here, Ben. In fact I hope we can still continue to have a 
productive discussion here.


I'm speaking on my own view now, and I'm happy to be wrong and learn but 
I wanted to explore how far we can bring the work around standalone 
architecture. If it was worth exploring making it "multi-node" somehow, 
what would be our technical challenges and more than anything else: what 
use-case we would enable.


I'm actually quite happy to see that people already looked at some of 
these challenges before (see what Giulio / James / Steve H. already 
worked on), so I guess it makes sense to continue the investigation.
We are not making any decision right now in what API we plan to use. The 
current production architecture is still undercloud + overcloud, and our 
day 2 operations are done by Mistral/Heat for now but as we transition 
more to Ansible I think we wanted to explore more options.


I hope this little background helped.


Yeah, I realize now that I invented some requirements that you didn't 
actually state in your original email.  Slap on the wrist to me for poor 
reading comprehension. :-)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes

2018-07-20 Thread Ben Nemec 



On 07/20/2018 02:53 PM, James Slagle wrote:

On Thu, Jul 19, 2018 at 7:13 PM, Ben Nemec  wrote:



On 07/19/2018 03:37 PM, Emilien Macchi wrote:


Today I played a little bit with Standalone deployment [1] to deploy a
single OpenStack cloud without the need of an undercloud and overcloud.
The use-case I am testing is the following:
"As an operator, I want to deploy a single node OpenStack, that I can
extend with remote compute nodes on the edge when needed."

We still have a bunch of things to figure out so it works out of the box,
but so far I was able to build something that worked, and I found useful to
share it early to gather some feedback:
https://gitlab.com/emacchi/tripleo-standalone-edge

Keep in mind this is a proof of concept, based on upstream documentation
and re-using 100% what is in TripleO today. The only thing I'm doing is to
change the environment and the roles for the remote compute node.
I plan to work on cleaning the manual steps that I had to do to make it
working, like hardcoding some hiera parameters and figure out how to
override ServiceNetmap.

Anyway, feel free to test / ask questions / provide feedback.



What is the benefit of doing this over just using deployed server to install
a remote server from the central management system?  You need to have
connectivity back to the central location anyway.  Won't this become
unwieldy with a large number of edge nodes?  I thought we told people not to
use Packstack for multi-node deployments for exactly that reason.

I guess my concern is that eliminating the undercloud makes sense for
single-node PoC's and development work, but for what sounds like a
production workload I feel like you're cutting off your nose to spite your
face.  In the interest of saving one VM's worth of resources, now all of
your day 2 operations have no built-in orchestration.  Every time you want
to change a configuration it's "copy new script to system, ssh to system,
run script, repeat for all systems.  So maybe this is a backdoor way to make
Ansible our API? ;-)


I believe Emilien was looking at this POC in part because of some
input from me, so I will attempt to address your questions
constructively.

What you're looking at here is exactly a POC. The deployment is a POC
using the experimental standalone code. I think the use case as
presented by Emilien is something worth considering:


"As an operator, I want to deploy a single node OpenStack, that I can
extend with remote compute nodes on the edge when needed."


I wouldn't interpret that to mean much of anything around eliminating
the undercloud, other than what is stated for the use case. I feel
that  jumping to eliminating the undercloud would be an over
simplification. The goal of the POC isn't packstack parity, or even
necessarily a packstack like architecture.


Okay, this was the main disconnect for me.  I got the impression from 
the discussion up til now that eliminating the undercloud was part of 
the requirements.  Looking back at Emilien's original email I think I 
conflated the standalone PoC description with the use-case description. 
My bad.




One of the goals is to see if we can deploy separate disconnected
stacks for Control and Compute. The standalone work happens to be a
good way to test out some of the work around that. The use case was
written to help describe and provide an overall picture of what is
going on with this specific POC, with a focus towards the edge use
case.

You make some points about centralized management and connectivity
back to the central location. Those are the exact sorts of things we
are thinking about when we consider how we will address edge
deployments. If you haven't had a chance yet, check out the Edge
Computing whitepaper from the foundation:

https://www.openstack.org/assets/edge/OpenStack-EdgeWhitepaper-v3-online.pdf

Particularly the challenges outlined around management and deployment
tooling. For lack of anything better I'm calling these the 3 D's:
- Decentralized
- Distributed
- Disconnected

How can TripleO address any of these?

For Decentralized, I'd like to see better separation between the
planning and application of the deployment in TripleO. TripleO has had
the concept of a plan for quite a while, and we've been using it very
effectively for our deployment, but it is somewhat hidden from the
operator. It's not entirely clear to the user that there is any
separation between the plan and the stack, and what benefit there even
is in the plan.


+1.  I was disappointed that we didn't adopt the plan as more of a 
first-class citizen for cli deployments after it was implemented.




I'd like to address some of that through API improvements around plan
management and making the plan the top level thing being managed
instead of a deployment. We're already moving in this direction with
config-download and a lot of the changes we've made during Queens.

For better or worse, some other tools like Terraform call this out as
one their main

Re: [openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes

2018-07-20 Thread James Slagle 
On Thu, Jul 19, 2018 at 7:13 PM, Ben Nemec  wrote:
>
>
> On 07/19/2018 03:37 PM, Emilien Macchi wrote:
>>
>> Today I played a little bit with Standalone deployment [1] to deploy a
>> single OpenStack cloud without the need of an undercloud and overcloud.
>> The use-case I am testing is the following:
>> "As an operator, I want to deploy a single node OpenStack, that I can
>> extend with remote compute nodes on the edge when needed."
>>
>> We still have a bunch of things to figure out so it works out of the box,
>> but so far I was able to build something that worked, and I found useful to
>> share it early to gather some feedback:
>> https://gitlab.com/emacchi/tripleo-standalone-edge
>>
>> Keep in mind this is a proof of concept, based on upstream documentation
>> and re-using 100% what is in TripleO today. The only thing I'm doing is to
>> change the environment and the roles for the remote compute node.
>> I plan to work on cleaning the manual steps that I had to do to make it
>> working, like hardcoding some hiera parameters and figure out how to
>> override ServiceNetmap.
>>
>> Anyway, feel free to test / ask questions / provide feedback.
>
>
> What is the benefit of doing this over just using deployed server to install
> a remote server from the central management system?  You need to have
> connectivity back to the central location anyway.  Won't this become
> unwieldy with a large number of edge nodes?  I thought we told people not to
> use Packstack for multi-node deployments for exactly that reason.
>
> I guess my concern is that eliminating the undercloud makes sense for
> single-node PoC's and development work, but for what sounds like a
> production workload I feel like you're cutting off your nose to spite your
> face.  In the interest of saving one VM's worth of resources, now all of
> your day 2 operations have no built-in orchestration.  Every time you want
> to change a configuration it's "copy new script to system, ssh to system,
> run script, repeat for all systems.  So maybe this is a backdoor way to make
> Ansible our API? ;-)

I believe Emilien was looking at this POC in part because of some
input from me, so I will attempt to address your questions
constructively.

What you're looking at here is exactly a POC. The deployment is a POC
using the experimental standalone code. I think the use case as
presented by Emilien is something worth considering:

>> "As an operator, I want to deploy a single node OpenStack, that I can
>> extend with remote compute nodes on the edge when needed."

I wouldn't interpret that to mean much of anything around eliminating
the undercloud, other than what is stated for the use case. I feel
that  jumping to eliminating the undercloud would be an over
simplification. The goal of the POC isn't packstack parity, or even
necessarily a packstack like architecture.

One of the goals is to see if we can deploy separate disconnected
stacks for Control and Compute. The standalone work happens to be a
good way to test out some of the work around that. The use case was
written to help describe and provide an overall picture of what is
going on with this specific POC, with a focus towards the edge use
case.

You make some points about centralized management and connectivity
back to the central location. Those are the exact sorts of things we
are thinking about when we consider how we will address edge
deployments. If you haven't had a chance yet, check out the Edge
Computing whitepaper from the foundation:

https://www.openstack.org/assets/edge/OpenStack-EdgeWhitepaper-v3-online.pdf

Particularly the challenges outlined around management and deployment
tooling. For lack of anything better I'm calling these the 3 D's:
- Decentralized
- Distributed
- Disconnected

How can TripleO address any of these?

For Decentralized, I'd like to see better separation between the
planning and application of the deployment in TripleO. TripleO has had
the concept of a plan for quite a while, and we've been using it very
effectively for our deployment, but it is somewhat hidden from the
operator. It's not entirely clear to the user that there is any
separation between the plan and the stack, and what benefit there even
is in the plan.

I'd like to address some of that through API improvements around plan
management and making the plan the top level thing being managed
instead of a deployment. We're already moving in this direction with
config-download and a lot of the changes we've made during Queens.

For better or worse, some other tools like Terraform call this out as
one their main differentiators:

https://www.terraform.io/intro/vs/cloudformation.html (3rd paragraph).

TripleO has long separated the planning and application phases. We
just need to do a better job at developing useful features around that
work. The UI has been taking advantage of it more than anything else
at this point. I'd like to focus a bit more on what benefits we get
from the plan, and how we can turn these

Re: [openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes

2018-07-20 Thread Harald Jensås 
On Fri, 2018-07-20 at 15:06 -0400, Emilien Macchi wrote:
> 
> 
> On Fri, Jul 20, 2018 at 2:55 PM Ben Nemec 
> wrote:
> > Okay, based on a private conversation this is coming off as way
> > more 
> > troll-ish than I intended.  I don't understand where this work is
> > going, 
> > but I don't really need to so I'll step back from the discussion. 
> > Apologies for any offense.
> 
> No offense here, Ben. In fact I hope we can still continue to have a
> productive discussion here.
> 
> I'm speaking on my own view now, and I'm happy to be wrong and learn
> but I wanted to explore how far we can bring the work around
> standalone architecture. If it was worth exploring making it "multi-
> node" somehow, what would be our technical challenges and more than
> anything else: what use-case we would enable.
> 
> I'm actually quite happy to see that people already looked at some of
> these challenges before (see what Giulio / James / Steve H. already
> worked on), so I guess it makes sense to continue the investigation.
> We are not making any decision right now in what API we plan to use.
> The current production architecture is still undercloud + overcloud,
> and our day 2 operations are done by Mistral/Heat for now but as we
> transition more to Ansible I think we wanted to explore more options.
> 
> I hope this little background helped.
> Thanks,
> -- 
> Emilien Macchi
> 

The split-stack work is interesting.

I'm however not convinced driving the standalone for the edge use
cases. (Like Ben I don't have enough background ...) However, this is
the spec of an edge user: https://review.openstack.org/543936 - they
want ironic to deploy their nodes and I bet choosing os-net-config is a
tripleo influenced choice ... 

I think for these users an undercloud that can deploy multiple
overclouds would make more sense. I.e Deploy one undercloud and use
that to deploy a number of overclouds.

I imagine split stack being used to separate compute and controllers.
Something like: controlplane-overcloud-a + compute-overcloud-a0 +
compute-overcloud-a1 + compute-overcloud-a2. 3x stacks building one
cloud using split-stack. Then the undercloud must be able to deploy b,
c, d etc stack sets similar to the a stacks.

This keeps the central management system but we can manage multiple
clouds and for edge-cases we can do scale/update/upgrade operations on
the stack for compute/storage nodes in each edge individually etc.


--
Harald

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes

2018-07-20 Thread Emilien Macchi 
On Fri, Jul 20, 2018 at 2:55 PM Ben Nemec  wrote:

> Okay, based on a private conversation this is coming off as way more
> troll-ish than I intended.  I don't understand where this work is going,
> but I don't really need to so I'll step back from the discussion.
> Apologies for any offense.
>

No offense here, Ben. In fact I hope we can still continue to have a
productive discussion here.

I'm speaking on my own view now, and I'm happy to be wrong and learn but I
wanted to explore how far we can bring the work around standalone
architecture. If it was worth exploring making it "multi-node" somehow,
what would be our technical challenges and more than anything else: what
use-case we would enable.

I'm actually quite happy to see that people already looked at some of these
challenges before (see what Giulio / James / Steve H. already worked on),
so I guess it makes sense to continue the investigation.
We are not making any decision right now in what API we plan to use. The
current production architecture is still undercloud + overcloud, and our
day 2 operations are done by Mistral/Heat for now but as we transition more
to Ansible I think we wanted to explore more options.

I hope this little background helped.
Thanks,
-- 
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes

2018-07-20 Thread Ben Nemec 
Okay, based on a private conversation this is coming off as way more 
troll-ish than I intended.  I don't understand where this work is going, 
but I don't really need to so I'll step back from the discussion. 
Apologies for any offense.


-Ben

On 07/20/2018 12:20 PM, Ben Nemec wrote:



On 07/20/2018 01:18 AM, Bogdan Dobrelya wrote:

On 7/20/18 2:13 AM, Ben Nemec wrote:



On 07/19/2018 03:37 PM, Emilien Macchi wrote:
Today I played a little bit with Standalone deployment [1] to deploy 
a single OpenStack cloud without the need of an undercloud and 
overcloud.

The use-case I am testing is the following:
"As an operator, I want to deploy a single node OpenStack, that I 
can extend with remote compute nodes on the edge when needed."


We still have a bunch of things to figure out so it works out of the 
box, but so far I was able to build something that worked, and I 
found useful to share it early to gather some feedback:

https://gitlab.com/emacchi/tripleo-standalone-edge

Keep in mind this is a proof of concept, based on upstream 
documentation and re-using 100% what is in TripleO today. The only 
thing I'm doing is to change the environment and the roles for the 
remote compute node.
I plan to work on cleaning the manual steps that I had to do to make 
it working, like hardcoding some hiera parameters and figure out how 
to override ServiceNetmap.


Anyway, feel free to test / ask questions / provide feedback.


What is the benefit of doing this over just using deployed server to 
install a remote server from the central management system?  You need 
to have connectivity back to the central location anyway.  Won't this 
become unwieldy with a large number of edge nodes?  I thought we told 
people not to use Packstack for multi-node deployments for exactly 
that reason.


I guess my concern is that eliminating the undercloud makes sense for 
single-node PoC's and development work, but for what sounds like a 
production workload I feel like you're cutting off your nose to spite 
your face.  In the interest of saving one VM's worth of resources, 
now all of your day 2 operations have no built-in orchestration.  
Every time you want to change a configuration it's "copy new script 
to system, ssh to system, run script, repeat for all systems.  So 
maybe this is a backdoor way to make Ansible our API? ;-)


Ansible may orchestrate that for day 2. Deploying Heat stacks is 
already made ephemeral for standalone/underclouds so only thing you'll 
need for day 2 is ansible really. Hence, the need of undercloud 
shrinks into having an ansible control node, like your laptop, to 
control all clouds via inventory.


So I guess the answer to my last question is yes. :-)

Are we planning to reimplement all of our API workflows in Ansible or 
are users expected to do that themselves?


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes

2018-07-20 Thread Ben Nemec 



On 07/20/2018 01:18 AM, Bogdan Dobrelya wrote:

On 7/20/18 2:13 AM, Ben Nemec wrote:



On 07/19/2018 03:37 PM, Emilien Macchi wrote:
Today I played a little bit with Standalone deployment [1] to deploy 
a single OpenStack cloud without the need of an undercloud and 
overcloud.

The use-case I am testing is the following:
"As an operator, I want to deploy a single node OpenStack, that I can 
extend with remote compute nodes on the edge when needed."


We still have a bunch of things to figure out so it works out of the 
box, but so far I was able to build something that worked, and I 
found useful to share it early to gather some feedback:

https://gitlab.com/emacchi/tripleo-standalone-edge

Keep in mind this is a proof of concept, based on upstream 
documentation and re-using 100% what is in TripleO today. The only 
thing I'm doing is to change the environment and the roles for the 
remote compute node.
I plan to work on cleaning the manual steps that I had to do to make 
it working, like hardcoding some hiera parameters and figure out how 
to override ServiceNetmap.


Anyway, feel free to test / ask questions / provide feedback.


What is the benefit of doing this over just using deployed server to 
install a remote server from the central management system?  You need 
to have connectivity back to the central location anyway.  Won't this 
become unwieldy with a large number of edge nodes?  I thought we told 
people not to use Packstack for multi-node deployments for exactly 
that reason.


I guess my concern is that eliminating the undercloud makes sense for 
single-node PoC's and development work, but for what sounds like a 
production workload I feel like you're cutting off your nose to spite 
your face.  In the interest of saving one VM's worth of resources, now 
all of your day 2 operations have no built-in orchestration.  Every 
time you want to change a configuration it's "copy new script to 
system, ssh to system, run script, repeat for all systems.  So maybe 
this is a backdoor way to make Ansible our API? ;-)


Ansible may orchestrate that for day 2. Deploying Heat stacks is already 
made ephemeral for standalone/underclouds so only thing you'll need for 
day 2 is ansible really. Hence, the need of undercloud shrinks into 
having an ansible control node, like your laptop, to control all clouds 
via inventory.


So I guess the answer to my last question is yes. :-)

Are we planning to reimplement all of our API workflows in Ansible or 
are users expected to do that themselves?


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes

2018-07-20 Thread Emilien Macchi 
On Fri, Jul 20, 2018 at 7:43 AM Emilien Macchi  wrote:

> On Fri, Jul 20, 2018 at 7:09 AM Emilien Macchi  wrote:
>
>> Yeah I thought about this one too but I didn't have this challenge since
>> I just wanted nova-compute & neutron-ovs-agent running on the edge.
>>
>
> Actually I just faced it:
> Error: Failed to perform requested operation on instance "my-vm", the
> instance has an error status: Please try again later [Error: Host
> 'standalone-cpu-edge.localdomain' is not mapped to any cell].
>
> I had to manually add the edge compute on the central node, so yeah we
> need to figure that out for the compute as well (unless I missed something
> in the nova config).
>

Nevermind, I had to set NovaSchedulerDiscoverHostsInCellsInterval to 300,
so nova-schedule checks for new compute nodes every 300s and include them
in the cell.
-- 
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes

2018-07-20 Thread James Slagle 
On Fri, Jul 20, 2018 at 7:09 AM, Emilien Macchi  wrote:
>
>
> On Fri, Jul 20, 2018 at 4:20 AM Giulio Fidente  wrote:
> [...]
>>
>> I have started experimenting with edge deployments to help out on the
>> split-controplane spec [1], which Steven started addressing
>>
>> I was able to deploy multiple stacks and isolated Ceph clusters, there
>> are some bits missing to provision a working configuration for
>> nova-compute to the edge services, but we could probably collect/export
>> the necessary outputs from the parent stack (eg. rabbit connection
>> infos) and feed the edge stacks with those.
>
>
> Indeed, I faced the exact same problems. I could hardcode the rabbit
> password and memcache IP via hieradata extraconfig, James showed me
> AllNodesExtraMapData done via https://review.openstack.org/#/c/581080/ which
> I'll probably give a try.
> However I couldn't set keystone url for nova / neutron (they are taken from
> ServiceNetMap).
> James pointed out to me this patch: https://review.openstack.org/#/c/521929/

Emilien/Giulio:

These are 3 patches (2 are from shardy) that I've been testing with
split-controlplane:

https://review.openstack.org/#/c/521928/
https://review.openstack.org/#/c/521929/
https://review.openstack.org/#/c/581080/

I'll pull some docs together if I have some initial success.





-- 
-- James Slagle
--

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes

2018-07-20 Thread Emilien Macchi 
On Fri, Jul 20, 2018 at 7:09 AM Emilien Macchi  wrote:

> Yeah I thought about this one too but I didn't have this challenge since I
> just wanted nova-compute & neutron-ovs-agent running on the edge.
>

Actually I just faced it:
Error: Failed to perform requested operation on instance "my-vm", the
instance has an error status: Please try again later [Error: Host
'standalone-cpu-edge.localdomain' is not mapped to any cell].

I had to manually add the edge compute on the central node, so yeah we need
to figure that out for the compute as well (unless I missed something in
the nova config).
-- 
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes

2018-07-20 Thread Emilien Macchi 
On Fri, Jul 20, 2018 at 4:20 AM Giulio Fidente  wrote:
[...]

> I have started experimenting with edge deployments to help out on the
> split-controplane spec [1], which Steven started addressing
>
> I was able to deploy multiple stacks and isolated Ceph clusters, there
> are some bits missing to provision a working configuration for
> nova-compute to the edge services, but we could probably collect/export
> the necessary outputs from the parent stack (eg. rabbit connection
> infos) and feed the edge stacks with those.
>

Indeed, I faced the exact same problems. I could hardcode the rabbit
password and memcache IP via hieradata extraconfig, James showed
me AllNodesExtraMapData done via https://review.openstack.org/#/c/581080/
which I'll probably give a try.
However I couldn't set keystone url for nova / neutron (they are taken from
ServiceNetMap).
James pointed out to me this patch: https://review.openstack.org/#/c/521929/
- Do you think we should re-use the service net map from the central node,
on the edge compute node?

A much bigger challenge seems to me that for some services (eg. glance
> or cinder) we need to "refresh" the configuration of the controlplane
> nodes to push the details of the newly deployed ceph clusters (backends)
> of the edge nodes as backends for the controlplane services.
>

Yeah I thought about this one too but I didn't have this challenge since I
just wanted nova-compute & neutron-ovs-agent running on the edge.

Alternatively, we could opt for the deployment of cinder-volume
> instances on the edge nodes, but we would still have the same problem
> for glance and possibly other services.
>

For now the only thing I see is to manually update the config on the
central node and run the deployment again, which should reconfigure the
containers.

I'd like to discuss further this topic at the PTG to gether more
> feedback so I added a bullet to the pad with the Stein PTG topics [2].


It would be awesome to spend time on this topic! Thanks for bringing this
blueprint up! Indeed I hope we'll make progress on this one at the PTG,
which is why I sent this email really early to groom some ideas.


> 1. https://blueprints.launchpad.net/tripleo/+spec/split-controlplane
> 2. https://etherpad.openstack.org/p/tripleo-ptg-stein


Thanks,
-- 
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes

2018-07-20 Thread Giulio Fidente 
On 07/19/2018 10:37 PM, Emilien Macchi wrote:
> Today I played a little bit with Standalone deployment [1] to deploy a
> single OpenStack cloud without the need of an undercloud and overcloud.
> The use-case I am testing is the following:
> "As an operator, I want to deploy a single node OpenStack, that I can
> extend with remote compute nodes on the edge when needed."
> 
> We still have a bunch of things to figure out so it works out of the
> box, but so far I was able to build something that worked, and I found
> useful to share it early to gather some feedback:
>   https://gitlab.com/emacchi/tripleo-standalone-edge
> 
> Keep in mind this is a proof of concept, based on upstream documentation
> and re-using 100% what is in TripleO today. The only thing I'm doing is
> to change the environment and the roles for the remote compute node.
> I plan to work on cleaning the manual steps that I had to do to make it
> working, like hardcoding some hiera parameters and figure out how to
> override ServiceNetmap.
> 
> Anyway, feel free to test / ask questions / provide feedback.

hi Emilien,

thanks for sharing this.

I have started experimenting with edge deployments to help out on the
split-controplane spec [1], which Steven started addressing

I was able to deploy multiple stacks and isolated Ceph clusters, there
are some bits missing to provision a working configuration for
nova-compute to the edge services, but we could probably collect/export
the necessary outputs from the parent stack (eg. rabbit connection
infos) and feed the edge stacks with those.

A much bigger challenge seems to me that for some services (eg. glance
or cinder) we need to "refresh" the configuration of the controlplane
nodes to push the details of the newly deployed ceph clusters (backends)
of the edge nodes as backends for the controlplane services.

Alternatively, we could opt for the deployment of cinder-volume
instances on the edge nodes, but we would still have the same problem
for glance and possibly other services.

I'd like to discuss further this topic at the PTG to gether more
feedback so I added a bullet to the pad with the Stein PTG topics [2].

1. https://blueprints.launchpad.net/tripleo/+spec/split-controlplane
2. https://etherpad.openstack.org/p/tripleo-ptg-stein

-- 
Giulio Fidente
GPG KEY: 08D733BA

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes

2018-07-20 Thread Bogdan Dobrelya 

On 7/20/18 2:13 AM, Ben Nemec wrote:



On 07/19/2018 03:37 PM, Emilien Macchi wrote:
Today I played a little bit with Standalone deployment [1] to deploy a 
single OpenStack cloud without the need of an undercloud and overcloud.

The use-case I am testing is the following:
"As an operator, I want to deploy a single node OpenStack, that I can 
extend with remote compute nodes on the edge when needed."


We still have a bunch of things to figure out so it works out of the 
box, but so far I was able to build something that worked, and I found 
useful to share it early to gather some feedback:

https://gitlab.com/emacchi/tripleo-standalone-edge

Keep in mind this is a proof of concept, based on upstream 
documentation and re-using 100% what is in TripleO today. The only 
thing I'm doing is to change the environment and the roles for the 
remote compute node.
I plan to work on cleaning the manual steps that I had to do to make 
it working, like hardcoding some hiera parameters and figure out how 
to override ServiceNetmap.


Anyway, feel free to test / ask questions / provide feedback.


What is the benefit of doing this over just using deployed server to 
install a remote server from the central management system?  You need to 
have connectivity back to the central location anyway.  Won't this 
become unwieldy with a large number of edge nodes?  I thought we told 
people not to use Packstack for multi-node deployments for exactly that 
reason.


I guess my concern is that eliminating the undercloud makes sense for 
single-node PoC's and development work, but for what sounds like a 
production workload I feel like you're cutting off your nose to spite 
your face.  In the interest of saving one VM's worth of resources, now 
all of your day 2 operations have no built-in orchestration.  Every time 
you want to change a configuration it's "copy new script to system, ssh 
to system, run script, repeat for all systems.  So maybe this is a 
backdoor way to make Ansible our API? ;-)


Ansible may orchestrate that for day 2. Deploying Heat stacks is already 
made ephemeral for standalone/underclouds so only thing you'll need for 
day 2 is ansible really. Hence, the need of undercloud shrinks into 
having an ansible control node, like your laptop, to control all clouds 
via inventory.




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes

2018-07-19 Thread Ben Nemec 



On 07/19/2018 03:37 PM, Emilien Macchi wrote:
Today I played a little bit with Standalone deployment [1] to deploy a 
single OpenStack cloud without the need of an undercloud and overcloud.

The use-case I am testing is the following:
"As an operator, I want to deploy a single node OpenStack, that I can 
extend with remote compute nodes on the edge when needed."


We still have a bunch of things to figure out so it works out of the 
box, but so far I was able to build something that worked, and I found 
useful to share it early to gather some feedback:

https://gitlab.com/emacchi/tripleo-standalone-edge

Keep in mind this is a proof of concept, based on upstream documentation 
and re-using 100% what is in TripleO today. The only thing I'm doing is 
to change the environment and the roles for the remote compute node.
I plan to work on cleaning the manual steps that I had to do to make it 
working, like hardcoding some hiera parameters and figure out how to 
override ServiceNetmap.


Anyway, feel free to test / ask questions / provide feedback.


What is the benefit of doing this over just using deployed server to 
install a remote server from the central management system?  You need to 
have connectivity back to the central location anyway.  Won't this 
become unwieldy with a large number of edge nodes?  I thought we told 
people not to use Packstack for multi-node deployments for exactly that 
reason.


I guess my concern is that eliminating the undercloud makes sense for 
single-node PoC's and development work, but for what sounds like a 
production workload I feel like you're cutting off your nose to spite 
your face.  In the interest of saving one VM's worth of resources, now 
all of your day 2 operations have no built-in orchestration.  Every time 
you want to change a configuration it's "copy new script to system, ssh 
to system, run script, repeat for all systems.  So maybe this is a 
backdoor way to make Ansible our API? ;-)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] prototype with standalone mode and remote edge compute nodes

2018-07-19 Thread Emilien Macchi 
Today I played a little bit with Standalone deployment [1] to deploy a
single OpenStack cloud without the need of an undercloud and overcloud.
The use-case I am testing is the following:
"As an operator, I want to deploy a single node OpenStack, that I can
extend with remote compute nodes on the edge when needed."

We still have a bunch of things to figure out so it works out of the box,
but so far I was able to build something that worked, and I found useful to
share it early to gather some feedback:
  https://gitlab.com/emacchi/tripleo-standalone-edge

Keep in mind this is a proof of concept, based on upstream documentation
and re-using 100% what is in TripleO today. The only thing I'm doing is to
change the environment and the roles for the remote compute node.
I plan to work on cleaning the manual steps that I had to do to make it
working, like hardcoding some hiera parameters and figure out how to
override ServiceNetmap.

Anyway, feel free to test / ask questions / provide feedback.

Thanks,
[1]
https://docs.openstack.org/tripleo-docs/latest/install/containers_deployment/standalone.html
-- 
Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev