Re: [Openstack] unexpected distribution of compute instances in queens
> > > Have you set the placement_randomize_allocation_candidates CONF option > and are still seeing the packing behaviour? > > No I haven't. Where would be the place to do that? In a nova.conf somewhere that the nova-scheduler containers on the controller hosts could pick it up? Just about to deploy for realz with about forty x86 compute nodes, so it would be really nice to sort this first. :) -- MC ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] unexpected distribution of compute instances in queens
On 11/30/2018 02:53 AM, Mike Carden wrote: I'm seeing a similar issue in Queens deployed via tripleo. Two x86 compute nodes and one ppc64le node and host aggregates for virtual instances and baremetal (x86) instances. Baremetal on x86 is working fine. All VMs get deployed to compute-0. I can live migrate VMs to compute-1 and all is well, but I tire of being the 'meatspace scheduler'. LOL, I love that term and will have to remember to use it in the future. I've looked at the nova.conf in the various nova-xxx containers on the controllers, but I have failed to discern the root of this issue. Have you set the placement_randomize_allocation_candidates CONF option and are still seeing the packing behaviour? Best, -jay ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] [Pike][Neutron] L3 metering with DVR doesn't work
Hello Brian,
Thanks for the info.
I looked into the code for the metering agent and discovered the following:
1. The metering agent on compute nodes doesn't get notified about DVR
routers running on the node.
2. For DVR routers it tries to meter the rfp- interface(for floating
ips) on the snat- namespace. This is wrong. The rfp- interface lies on
the qrouter- namespace on compute nodes. Also, there is a qg- interface
on the snat- namespace on network nodes (for performing NAT) which
should be metered too.
3. There is a race condition whereby the metering agent is notified
about a router before its namespaces are created. The agent ends up not
adding the metering rules for those namespaces and this leads to
unrecorded traffic.
I addressed those issues in a change:
https://review.openstack.org/#/c/621165/. Any feedback is appreciated.
Best regards,
Alex
On 26/10/2018 21:49, Brian Haley wrote:
On 10/25/2018 08:06 AM, Alexandru Sorodoc wrote:
Hello,
I'm trying to set up metering for neutron in Pike. I tested it with a
centralized router and it works, but when I try with a distributed
router it
doesn't record any usage samples. I have one compute node and one
network node
and I've created an instance with a floating ip.
The metering agent isn't very well maintained, and I don't see any
open bugs similar to this issue. The only thing I can remember is
this abandoned change regarding traffic counters for DVR routers -
https://review.openstack.org/#/c/486493/ but there was no follow-on
from the author.
The best thing to do would be to try and reproduce it on the master
branch (or Rocky) and file a bug.
> I think this is because the router is running on network1. Why is it
> running on
> network1 and why does it seem that the l3 agent on compute1 does the
actual
> routing?
The compute node will do all the routing when a floating IP is
associated, the router on network1 is for default snat traffic when
there is no floating IP and the instance tries to communicate out the
external network.
-Brian
openstack router show public-router2
+-++
| Field |
Value |
+-++
| admin_state_up |
UP |
| availability_zone_hints
| |
| availability_zones |
nova |
| created_at |
2018-10-05T12:07:32Z |
| description | |
| distributed |
True |
| external_gateway_info | {"network_id":
"b96473ce- |
| | 94f6-464f-a703-5285fb8ff3d3",
"enable_snat": true, |
| | "external_fixed_ips":
[{"subnet_id": |
| |
"6c08c3d9-7df1-4bec-b847-19f80b9d1764", |
| | "ip_address":
"192.168.252.102"}]} |
| flavor_id |
None |
| ha |
False |
| id |
37c1794b-58d1-4d0d-b34b-944ca411b86b |
| name |
public-router2 |
| project_id |
fe203109e67f4e39b066c9529f9fc35d |
| revision_number |
5 |
| routes | |
| status |
ACTIVE |
| tags | |
| updated_at |
2018-10-05T12:09:36Z |
+-++
openstack network agent list
+---++---+---+---+---+--+
| ID | Agent Type | Host | Availability Zone | Alive |
State | Binary |
+---++---+---+---+---+--+
| 14b9ea75- | L3 agent | compute1. | nova | :-) | UP |
neutron-l3-a |
| 1dc1-4e37 | | localdoma | | | | gent |
| -a2b0-508 | | in | | | | |
| 3d336916d | | | | | | |
| 26139ec1- | Metering | compute1. | None | :-) | UP |
neutron- |
| f4f9-4bb3 | agent | localdoma | | | | metering- |
| -aebb-c35 | | in | | | | agent |
| 3a36ed79c | | | | | | |
|
Re: [Openstack-operators] [openstack-dev] [nova] Would an api option to create an instance without powering on be useful?
On 11/30/18 6:06 AM, Matthew Booth wrote: I have a request to do $SUBJECT in relation to a V2V workflow. The use case here is conversion of a VM/Physical which was previously powered off. We want to move its data, but we don't want to be powering on stuff which wasn't previously on. This would involve an api change, and a hopefully very small change in drivers to support it. Technically I don't see it as an issue. However, is it a change we'd be willing to accept? Is there any good reason not to do this? Are there any less esoteric workflows which might use this feature? I don't know if it qualifies as less esoteric, but I would use this for OVB[1]. When we create the "baremetal" VMs there's no need to actually power them on since the first thing we do with them is shut them down again. Their initial footprint is pretty small so it's not a huge deal, but it is another potential use case for this feature. 1: https://openstack-virtual-baremetal.readthedocs.io/en/latest/introduction.html ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes
Still confused by: [base] -> [service] -> [+ puppet] not: [base] -> [puppet] and [base] -> [service] ? Thanks, Kevin From: Bogdan Dobrelya [bdobr...@redhat.com] Sent: Friday, November 30, 2018 5:31 AM To: Dan Prince; openstack-dev@lists.openstack.org; openstack-disc...@lists.openstack.org Subject: Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes On 11/30/18 1:52 PM, Dan Prince wrote: > On Fri, 2018-11-30 at 10:31 +0100, Bogdan Dobrelya wrote: >> On 11/29/18 6:42 PM, Jiří Stránský wrote: >>> On 28. 11. 18 18:29, Bogdan Dobrelya wrote: On 11/28/18 6:02 PM, Jiří Stránský wrote: > > >> Reiterating again on previous points: >> >> -I'd be fine removing systemd. But lets do it properly and >> not via 'rpm >> -ev --nodeps'. >> -Puppet and Ruby *are* required for configuration. We can >> certainly put >> them in a separate container outside of the runtime service >> containers >> but doing so would actually cost you much more >> space/bandwidth for each >> service container. As both of these have to get downloaded to >> each node >> anyway in order to generate config files with our current >> mechanisms >> I'm not sure this buys you anything. > > +1. I was actually under the impression that we concluded > yesterday on > IRC that this is the only thing that makes sense to seriously > consider. > But even then it's not a win-win -- we'd gain some security by > leaner > production images, but pay for it with space+bandwidth by > duplicating > image content (IOW we can help achieve one of the goals we had > in mind > by worsening the situation w/r/t the other goal we had in > mind.) > > Personally i'm not sold yet but it's something that i'd > consider if we > got measurements of how much more space/bandwidth usage this > would > consume, and if we got some further details/examples about how > serious > are the security concerns if we leave config mgmt tools in > runtime > images. > > IIRC the other options (that were brought forward so far) were > already > dismissed in yesterday's IRC discussion and on the reviews. > Bin/lib bind > mounting being too hacky and fragile, and nsenter not really > solving the > problem (because it allows us to switch to having different > bins/libs > available, but it does not allow merging the availability of > bins/libs > from two containers into a single context). > >> We are going in circles here I think > > +1. I think too much of the discussion focuses on "why it's bad > to have > config tools in runtime images", but IMO we all sorta agree > that it > would be better not to have them there, if it came at no cost. > > I think to move forward, it would be interesting to know: if we > do this > (i'll borrow Dan's drawing): > >> base container| --> |service container| --> |service >> container w/ > Puppet installed| > > How much more space and bandwidth would this consume per node > (e.g. > separately per controller, per compute). This could help with > decision > making. As I've already evaluated in the related bug, that is: puppet-* modules and manifests ~ 16MB puppet with dependencies ~61MB dependencies of the seemingly largest a dependency, systemd ~190MB that would be an extra layer size for each of the container images to be downloaded/fetched into registries. >>> >>> Thanks, i tried to do the math of the reduction vs. inflation in >>> sizes >>> as follows. I think the crucial point here is the layering. If we >>> do >>> this image layering: >>> base| --> |+ service| --> |+ Puppet| >>> >>> we'd drop ~267 MB from base image, but we'd be installing that to >>> the >>> topmost level, per-component, right? >> >> Given we detached systemd from puppet, cronie et al, that would be >> 267-190MB, so the math below would be looking much better > > Would it be worth writing a spec that summarizes what action items are > bing taken to optimize our base image with regards to the systemd? Perhaps it would be. But honestly, I see nothing biggie to require a full blown spec. Just changing RPM deps and layers for containers images. I'm tracking systemd changes here [0],[1],[2], btw (if accepted, it should be working as of fedora28(or 29) I hope) [0] https://review.rdoproject.org/r/#/q/topic:base-container-reduction [1] https://bugzilla.redhat.com/show_bug.cgi?id=1654659 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1654672 > > It seems like the general consenses is that cleaning up some of the RPM > dependencies so that we don't install Systemd is the biggest win. > > What confuses me is why are there still
Re: [openstack-dev] [nova] Would an api option to create an instance without powering on be useful?
On 11/30/18 6:06 AM, Matthew Booth wrote: I have a request to do $SUBJECT in relation to a V2V workflow. The use case here is conversion of a VM/Physical which was previously powered off. We want to move its data, but we don't want to be powering on stuff which wasn't previously on. This would involve an api change, and a hopefully very small change in drivers to support it. Technically I don't see it as an issue. However, is it a change we'd be willing to accept? Is there any good reason not to do this? Are there any less esoteric workflows which might use this feature? I don't know if it qualifies as less esoteric, but I would use this for OVB[1]. When we create the "baremetal" VMs there's no need to actually power them on since the first thing we do with them is shut them down again. Their initial footprint is pretty small so it's not a huge deal, but it is another potential use case for this feature. 1: https://openstack-virtual-baremetal.readthedocs.io/en/latest/introduction.html __ 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-operators] [openstack-dev] [nova] Would an api option to create an instance without powering on be useful?
On Fri, 2018-11-30 at 09:40 -0500, Mohammed Naser wrote: > > > On Fri, Nov 30, 2018 at 7:07 AM Matthew Booth wrote: > > I have a request to do $SUBJECT in relation to a V2V workflow. The use > > case here is conversion of a VM/Physical which was previously powered > > off. We want to move its data, but we don't want to be powering on > > stuff which wasn't previously on. > > > > This would involve an api change, and a hopefully very small change in > > drivers to support it. Technically I don't see it as an issue. > > > > However, is it a change we'd be willing to accept? Is there any good > > reason not to do this? Are there any less esoteric workflows which > > might use this feature? > > If you upload an image of said VM which you don't boot, you'd really be > accomplishing the same thing, no? > > Unless you want to be in a state where you want the VM to be there but > sitting in SHUTOFF state i think the intent was to have a vm ready to go with ips/ports, volumes exctra all created so you can quickly start it when needed. if that is the case another alternitive which might be more public cloud freidly form a wallet perspecitve would be the ablity to create a shelved isntace. that way all the ports ectra would be logically created but it would not be consumeing any compute resources. > > > Matt > > -- > > Matthew Booth > > Red Hat OpenStack Engineer, Compute DFG > > > > Phone: +442070094448 (UK) > > > > ___ > > OpenStack-operators mailing list > > OpenStack-operators@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > __ > 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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [Openstack-operators] [nova] Would an api option to create an instance without powering on be useful?
On Fri, 2018-11-30 at 09:40 -0500, Mohammed Naser wrote: > > > On Fri, Nov 30, 2018 at 7:07 AM Matthew Booth wrote: > > I have a request to do $SUBJECT in relation to a V2V workflow. The use > > case here is conversion of a VM/Physical which was previously powered > > off. We want to move its data, but we don't want to be powering on > > stuff which wasn't previously on. > > > > This would involve an api change, and a hopefully very small change in > > drivers to support it. Technically I don't see it as an issue. > > > > However, is it a change we'd be willing to accept? Is there any good > > reason not to do this? Are there any less esoteric workflows which > > might use this feature? > > If you upload an image of said VM which you don't boot, you'd really be > accomplishing the same thing, no? > > Unless you want to be in a state where you want the VM to be there but > sitting in SHUTOFF state i think the intent was to have a vm ready to go with ips/ports, volumes exctra all created so you can quickly start it when needed. if that is the case another alternitive which might be more public cloud freidly form a wallet perspecitve would be the ablity to create a shelved isntace. that way all the ports ectra would be logically created but it would not be consumeing any compute resources. > > > Matt > > -- > > Matthew Booth > > Red Hat OpenStack Engineer, Compute DFG > > > > Phone: +442070094448 (UK) > > > > ___ > > OpenStack-operators mailing list > > openstack-operat...@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > __ > 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][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes
On 11/29/18 6:42 PM, Jiří Stránský wrote: On 28. 11. 18 18:29, Bogdan Dobrelya wrote: On 11/28/18 6:02 PM, Jiří Stránský wrote: Reiterating again on previous points: -I'd be fine removing systemd. But lets do it properly and not via 'rpm -ev --nodeps'. -Puppet and Ruby *are* required for configuration. We can certainly put them in a separate container outside of the runtime service containers but doing so would actually cost you much more space/bandwidth for each service container. As both of these have to get downloaded to each node anyway in order to generate config files with our current mechanisms I'm not sure this buys you anything. +1. I was actually under the impression that we concluded yesterday on IRC that this is the only thing that makes sense to seriously consider. But even then it's not a win-win -- we'd gain some security by leaner production images, but pay for it with space+bandwidth by duplicating image content (IOW we can help achieve one of the goals we had in mind by worsening the situation w/r/t the other goal we had in mind.) Personally i'm not sold yet but it's something that i'd consider if we got measurements of how much more space/bandwidth usage this would consume, and if we got some further details/examples about how serious are the security concerns if we leave config mgmt tools in runtime images. IIRC the other options (that were brought forward so far) were already dismissed in yesterday's IRC discussion and on the reviews. Bin/lib bind mounting being too hacky and fragile, and nsenter not really solving the problem (because it allows us to switch to having different bins/libs available, but it does not allow merging the availability of bins/libs from two containers into a single context). We are going in circles here I think +1. I think too much of the discussion focuses on "why it's bad to have config tools in runtime images", but IMO we all sorta agree that it would be better not to have them there, if it came at no cost. I think to move forward, it would be interesting to know: if we do this (i'll borrow Dan's drawing): |base container| --> |service container| --> |service container w/ Puppet installed| How much more space and bandwidth would this consume per node (e.g. separately per controller, per compute). This could help with decision making. As I've already evaluated in the related bug, that is: puppet-* modules and manifests ~ 16MB puppet with dependencies ~61MB dependencies of the seemingly largest a dependency, systemd ~190MB that would be an extra layer size for each of the container images to be downloaded/fetched into registries. Thanks, i tried to do the math of the reduction vs. inflation in sizes as follows. I think the crucial point here is the layering. If we do this image layering: |base| --> |+ service| --> |+ Puppet| we'd drop ~267 MB from base image, but we'd be installing that to the topmost level, per-component, right? Given we detached systemd from puppet, cronie et al, that would be 267-190MB, so the math below would be looking much better In my basic deployment, undercloud seems to have 17 "components" (49 containers), overcloud controller 15 components (48 containers), and overcloud compute 4 components (7 containers). Accounting for overlaps, the total number of "components" used seems to be 19. (By "components" here i mean whatever uses a different ConfigImage than other services. I just eyeballed it but i think i'm not too far off the correct number.) So we'd subtract 267 MB from base image and add that to 19 leaf images used in this deployment. That means difference of +4.8 GB to the current image sizes. My /var/lib/registry dir on undercloud with all the images currently has 5.1 GB. We'd almost double that to 9.9 GB. Going from 5.1 to 9.9 GB seems like a lot of extra traffic for the CDNs (both external and e.g. internal within OpenStack Infra CI clouds). And for internal traffic between local registry and overcloud nodes, it gives +3.7 GB per controller and +800 MB per compute. That may not be so critical but still feels like a considerable downside. Another gut feeling is that this way of image layering would take longer time to build and to run the modify-image Ansible role which we use in CI, so that could endanger how our CI jobs fit into the time limit. We could also probably measure this but i'm not sure if it's worth spending the time. All in all i'd argue we should be looking at different options still. Given that we should decouple systemd from all/some of the dependencies (an example topic for RDO [0]), that could save a 190MB. But it seems we cannot break the love of puppet and systemd as it heavily relies on the latter and changing packaging like that would higly likely affect baremetal deployments with puppet and systemd co-operating. Ack :/ Long story short, we cannot shoot both rabbits with a single shot, not with puppet :) May be we could with
[openstack-dev] [nova] Would an api option to create an instance without powering on be useful?
I have a request to do $SUBJECT in relation to a V2V workflow. The use case here is conversion of a VM/Physical which was previously powered off. We want to move its data, but we don't want to be powering on stuff which wasn't previously on. This would involve an api change, and a hopefully very small change in drivers to support it. Technically I don't see it as an issue. However, is it a change we'd be willing to accept? Is there any good reason not to do this? Are there any less esoteric workflows which might use this feature? Matt -- Matthew Booth Red Hat OpenStack Engineer, Compute DFG Phone: +442070094448 (UK) __ 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][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes
On Fri, 2018-11-30 at 10:31 +0100, Bogdan Dobrelya wrote: > On 11/29/18 6:42 PM, Jiří Stránský wrote: > > On 28. 11. 18 18:29, Bogdan Dobrelya wrote: > > > On 11/28/18 6:02 PM, Jiří Stránský wrote: > > > > > > > > > > > > > Reiterating again on previous points: > > > > > > > > > > -I'd be fine removing systemd. But lets do it properly and > > > > > not via 'rpm > > > > > -ev --nodeps'. > > > > > -Puppet and Ruby *are* required for configuration. We can > > > > > certainly put > > > > > them in a separate container outside of the runtime service > > > > > containers > > > > > but doing so would actually cost you much more > > > > > space/bandwidth for each > > > > > service container. As both of these have to get downloaded to > > > > > each node > > > > > anyway in order to generate config files with our current > > > > > mechanisms > > > > > I'm not sure this buys you anything. > > > > > > > > +1. I was actually under the impression that we concluded > > > > yesterday on > > > > IRC that this is the only thing that makes sense to seriously > > > > consider. > > > > But even then it's not a win-win -- we'd gain some security by > > > > leaner > > > > production images, but pay for it with space+bandwidth by > > > > duplicating > > > > image content (IOW we can help achieve one of the goals we had > > > > in mind > > > > by worsening the situation w/r/t the other goal we had in > > > > mind.) > > > > > > > > Personally i'm not sold yet but it's something that i'd > > > > consider if we > > > > got measurements of how much more space/bandwidth usage this > > > > would > > > > consume, and if we got some further details/examples about how > > > > serious > > > > are the security concerns if we leave config mgmt tools in > > > > runtime > > > > images. > > > > > > > > IIRC the other options (that were brought forward so far) were > > > > already > > > > dismissed in yesterday's IRC discussion and on the reviews. > > > > Bin/lib bind > > > > mounting being too hacky and fragile, and nsenter not really > > > > solving the > > > > problem (because it allows us to switch to having different > > > > bins/libs > > > > available, but it does not allow merging the availability of > > > > bins/libs > > > > from two containers into a single context). > > > > > > > > > We are going in circles here I think > > > > > > > > +1. I think too much of the discussion focuses on "why it's bad > > > > to have > > > > config tools in runtime images", but IMO we all sorta agree > > > > that it > > > > would be better not to have them there, if it came at no cost. > > > > > > > > I think to move forward, it would be interesting to know: if we > > > > do this > > > > (i'll borrow Dan's drawing): > > > > > > > > > base container| --> |service container| --> |service > > > > > container w/ > > > > Puppet installed| > > > > > > > > How much more space and bandwidth would this consume per node > > > > (e.g. > > > > separately per controller, per compute). This could help with > > > > decision > > > > making. > > > > > > As I've already evaluated in the related bug, that is: > > > > > > puppet-* modules and manifests ~ 16MB > > > puppet with dependencies ~61MB > > > dependencies of the seemingly largest a dependency, systemd > > > ~190MB > > > > > > that would be an extra layer size for each of the container > > > images to be > > > downloaded/fetched into registries. > > > > Thanks, i tried to do the math of the reduction vs. inflation in > > sizes > > as follows. I think the crucial point here is the layering. If we > > do > > this image layering: > > > > > base| --> |+ service| --> |+ Puppet| > > > > we'd drop ~267 MB from base image, but we'd be installing that to > > the > > topmost level, per-component, right? > > Given we detached systemd from puppet, cronie et al, that would be > 267-190MB, so the math below would be looking much better Would it be worth writing a spec that summarizes what action items are bing taken to optimize our base image with regards to the systemd? It seems like the general consenses is that cleaning up some of the RPM dependencies so that we don't install Systemd is the biggest win. What confuses me is why are there still patches posted to move Puppet out of the base layer when we agree moving it out of the base layer would actually cause our resulting container image set to be larger in size. Dan > > > In my basic deployment, undercloud seems to have 17 "components" > > (49 > > containers), overcloud controller 15 components (48 containers), > > and > > overcloud compute 4 components (7 containers). Accounting for > > overlaps, > > the total number of "components" used seems to be 19. (By > > "components" > > here i mean whatever uses a different ConfigImage than other > > services. I > > just eyeballed it but i think i'm not too far off the correct > > number.) > > > > So we'd subtract 267 MB from base image and add that to 19 leaf > > images > > used in this
Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes
On 11/30/18 1:52 PM, Dan Prince wrote: On Fri, 2018-11-30 at 10:31 +0100, Bogdan Dobrelya wrote: On 11/29/18 6:42 PM, Jiří Stránský wrote: On 28. 11. 18 18:29, Bogdan Dobrelya wrote: On 11/28/18 6:02 PM, Jiří Stránský wrote: Reiterating again on previous points: -I'd be fine removing systemd. But lets do it properly and not via 'rpm -ev --nodeps'. -Puppet and Ruby *are* required for configuration. We can certainly put them in a separate container outside of the runtime service containers but doing so would actually cost you much more space/bandwidth for each service container. As both of these have to get downloaded to each node anyway in order to generate config files with our current mechanisms I'm not sure this buys you anything. +1. I was actually under the impression that we concluded yesterday on IRC that this is the only thing that makes sense to seriously consider. But even then it's not a win-win -- we'd gain some security by leaner production images, but pay for it with space+bandwidth by duplicating image content (IOW we can help achieve one of the goals we had in mind by worsening the situation w/r/t the other goal we had in mind.) Personally i'm not sold yet but it's something that i'd consider if we got measurements of how much more space/bandwidth usage this would consume, and if we got some further details/examples about how serious are the security concerns if we leave config mgmt tools in runtime images. IIRC the other options (that were brought forward so far) were already dismissed in yesterday's IRC discussion and on the reviews. Bin/lib bind mounting being too hacky and fragile, and nsenter not really solving the problem (because it allows us to switch to having different bins/libs available, but it does not allow merging the availability of bins/libs from two containers into a single context). We are going in circles here I think +1. I think too much of the discussion focuses on "why it's bad to have config tools in runtime images", but IMO we all sorta agree that it would be better not to have them there, if it came at no cost. I think to move forward, it would be interesting to know: if we do this (i'll borrow Dan's drawing): base container| --> |service container| --> |service container w/ Puppet installed| How much more space and bandwidth would this consume per node (e.g. separately per controller, per compute). This could help with decision making. As I've already evaluated in the related bug, that is: puppet-* modules and manifests ~ 16MB puppet with dependencies ~61MB dependencies of the seemingly largest a dependency, systemd ~190MB that would be an extra layer size for each of the container images to be downloaded/fetched into registries. Thanks, i tried to do the math of the reduction vs. inflation in sizes as follows. I think the crucial point here is the layering. If we do this image layering: base| --> |+ service| --> |+ Puppet| we'd drop ~267 MB from base image, but we'd be installing that to the topmost level, per-component, right? Given we detached systemd from puppet, cronie et al, that would be 267-190MB, so the math below would be looking much better Would it be worth writing a spec that summarizes what action items are bing taken to optimize our base image with regards to the systemd? Perhaps it would be. But honestly, I see nothing biggie to require a full blown spec. Just changing RPM deps and layers for containers images. I'm tracking systemd changes here [0],[1],[2], btw (if accepted, it should be working as of fedora28(or 29) I hope) [0] https://review.rdoproject.org/r/#/q/topic:base-container-reduction [1] https://bugzilla.redhat.com/show_bug.cgi?id=1654659 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1654672 It seems like the general consenses is that cleaning up some of the RPM dependencies so that we don't install Systemd is the biggest win. What confuses me is why are there still patches posted to move Puppet out of the base layer when we agree moving it out of the base layer would actually cause our resulting container image set to be larger in size. Dan In my basic deployment, undercloud seems to have 17 "components" (49 containers), overcloud controller 15 components (48 containers), and overcloud compute 4 components (7 containers). Accounting for overlaps, the total number of "components" used seems to be 19. (By "components" here i mean whatever uses a different ConfigImage than other services. I just eyeballed it but i think i'm not too far off the correct number.) So we'd subtract 267 MB from base image and add that to 19 leaf images used in this deployment. That means difference of +4.8 GB to the current image sizes. My /var/lib/registry dir on undercloud with all the images currently has 5.1 GB. We'd almost double that to 9.9 GB. Going from 5.1 to 9.9 GB seems like a lot of extra traffic for the CDNs (both external and e.g. internal within OpenStack Infra CI clouds). And for
Re: [openstack-dev] [Openstack-operators] [nova] Would an api option to create an instance without powering on be useful?
On Fri, Nov 30, 2018 at 7:07 AM Matthew Booth wrote: > I have a request to do $SUBJECT in relation to a V2V workflow. The use > case here is conversion of a VM/Physical which was previously powered > off. We want to move its data, but we don't want to be powering on > stuff which wasn't previously on. > > This would involve an api change, and a hopefully very small change in > drivers to support it. Technically I don't see it as an issue. > > However, is it a change we'd be willing to accept? Is there any good > reason not to do this? Are there any less esoteric workflows which > might use this feature? > If you upload an image of said VM which you don't boot, you'd really be accomplishing the same thing, no? Unless you want to be in a state where you want the VM to be there but sitting in SHUTOFF state > Matt > -- > Matthew Booth > Red Hat OpenStack Engineer, Compute DFG > > Phone: +442070094448 (UK) > > ___ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators -- Mohammed Naser — vexxhost - D. 514-316-8872 D. 800-910-1726 ext. 200 E. mna...@vexxhost.com W. http://vexxhost.com __ 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-operators] [nova] Would an api option to create an instance without powering on be useful?
On Fri, Nov 30, 2018 at 7:07 AM Matthew Booth wrote: > I have a request to do $SUBJECT in relation to a V2V workflow. The use > case here is conversion of a VM/Physical which was previously powered > off. We want to move its data, but we don't want to be powering on > stuff which wasn't previously on. > > This would involve an api change, and a hopefully very small change in > drivers to support it. Technically I don't see it as an issue. > > However, is it a change we'd be willing to accept? Is there any good > reason not to do this? Are there any less esoteric workflows which > might use this feature? > If you upload an image of said VM which you don't boot, you'd really be accomplishing the same thing, no? Unless you want to be in a state where you want the VM to be there but sitting in SHUTOFF state > Matt > -- > Matthew Booth > Red Hat OpenStack Engineer, Compute DFG > > Phone: +442070094448 (UK) > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators -- Mohammed Naser — vexxhost - D. 514-316-8872 D. 800-910-1726 ext. 200 E. mna...@vexxhost.com W. http://vexxhost.com ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
