Re: [openstack-dev] Multinode testing with devstack and neutron broken

[Matthew Van Dijk]

Not much to add here - I commented in 
review.openstack.org/378063
that they could set the default value of the flag to revert behaviour.
- Matt

On Oct 11, 2016, at 10:21 PM, Armando M. 
> wrote:



On 11 October 2016 at 18:20, Sean M. Collins 
> wrote:
Armando M. wrote:
> At this point I feel that changing the pool range is even less justified.
> If I had seen bug [4], I would have been against its fix, because you're
> absolutely right as the change being not backward compatible.

https://review.openstack.org/#/c/356026 was written by someone on the Trove 
team to
help them with their CI jobs IIRC.

CC'ing Matthew since he has more context. I went into the Trove channel
and asked them about reverting 356026. It doesn't seem like an option at
this point.

http://eavesdrop.openstack.org/irclogs/%23openstack-trove/%23openstack-trove.2016-09-30.log.html#t2016-09-30T17:53:08

A revert with no follow up is clearly not a viable option most of the times, 
and we clearly dug ourselves too deep now with [1]. Rather than making the use 
of subnet pools conditional as done in [1], IMO we should have made [2] 
conditional to preserve the existing provisioning behavior and let Trove 
override.

[1] Ic89ceca76afda67da5545111972c3348011f294f
[2] https://review.openstack.org/#/c/356026/




--
Sean M. Collins

__
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] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

[Matthew Van Dijk]

In the scenario of Trove supporting both tools what do you expect the
requirements for adding support for new databases will be? Are we
expecting to have to support both tools for approval from the
community?

Cheers,

Matt

On May 5, 2016, at 10:43 AM, Mariam John 
> wrote:


Victoria Martínez de la Cruz ---05/05/2016 08:12:33 AM---Hi all, A 
few things:

From:  Victoria Martínez de la Cruz 
>
To:  "OpenStack Development Mailing List (not for usage questions)" 
>
Date:  05/05/2016 08:12 AM
Subject:  Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] 
discussion of image building in Trove





Hi all,

A few things:

- I agree that moving from DIB to libguestfs is a bold move and that we should 
try to avoid changing tools unless highly necessary. The downsides we found for 
DIB are detailed in this spec [0] and Ethan (in this same thread) also added 
valid points on the Sahara case. My concern here is, should we stick with DIB 
just because is the standard for image creation? Shouldn't we take in 
consideration that some projects, like Sahara, are moving away from?

I think it would be worth trying to see if DIB can address the concerns raised 
by the different projects around image building and improve upon that. By 
improving DIB, I think all these projects and OpenStack in general can benefit 
from it.

- In the long term it would be ideal that we reach to a common solution for 
image creation for all the projects that need tailored images: Trove, Sahara, 
Octavia, Manila, and IIRC, Kolla and Cue.
- In the short term, I'm on board or working on having tools based on DIB for 
image creation in Trove.
- Amrith, Pete is working on the image creation process for Trove. The spec is 
up there [0]. I think is his work to kick-off that repository.

Best,

Victoria

[0] https://review.openstack.org/#/c/295274/

2016-05-04 23:20 GMT-03:00 Amrith Kumar 
>:

As we discussed at summit, (and consistent with all of the comments) we should 
move ahead with the project to advance the image builder for Trove and make it 
easier to build guest images for Trove by leveraging the DIB elements that we 
have in trove-integration.


To that end, the infra [1] and governance [2] changes have been submitted for 
review. The Launchpad tracker [3] has been registered.



I am working on taking the existing DIB elements in trove-integration and 
putting them in the new repository (openstack/trove-image-builder). I am also 
going to continue to watch this conversation and record any shortcomings with 
the existing DIB elements in Launchpad [3] and work on fixing those as well. 
Pete mentions one in his earlier email and I’ve logged that in Launchpad [4].



Thanks,



-amrith



[1] https://review.openstack.org/#/c/312805/

[2] https://review.openstack.org/#/c/312806/

[3] https://launchpad.net/trove-image-builder

[4] https://bugs.launchpad.net/trove-image-builder/+bug/1578454





From: Mariam John [mailto:mari...@us.ibm.com]
Sent: Wednesday, May 04, 2016 4:19 PM
To: OpenStack Development Mailing List (not for usage questions) 
>

Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila] discussion 
of image building in Trove



The way I see this, these are the 2 main concerns I have been hearing regarding 
image building in Trove:
1) making the process simple and easy for users
2) addressing the issue of security

I dont think there is any argument regarding the benefits of moving the 
database elements to a seperate repository and packaging and managing them from 
there.

It looks like the case that we make for whether to use libguestfs or DIB for 
image building are in the technical details of how image building happens and 
their nuances - assuming that ease of use & having a simple interface to build 
secure images matters most, I wonder if the end-users would be concerned about 
these details.

By addressing some of the issues like:
- moving the Trove elements to a new repository
- adding support for new distros
- creating a wrapper script for building an image -getting the Trove guest 
agent code & configuration files
- managing environment variables better

I believe it will make a huge improvement in terms of simplifying and improving 
the ease of use for end users and hence could be the low hanging fruit that we 
can implement in the mean time. I agree that switching from DIB to any other 
tool is a big step and we need to put alot of thought into it like many others 
have suggested. Like Pete mentioned earlier in one of the links, there are 
couple of other tools available for building images. I am sure we could make 
the case for 

[openstack-dev] [oslo.utils] allow strutils.mask_password to mask keys dynamically

[Matthew Van Dijk]

I’ve come across a use case for allowing dynamic keys to be made
secret. The hardcoded list is good for common keys, but there will be
cases where masking a custom value is useful without having to add it
to the hardcoded list.
I propose we add an optional parameter that is a list of secret_keys
whose values will be masked.
There is concern that this will lead to differing levels of security.
But I disagree as either the message will be masked before passing on
or mask_password will be called. In this case the developer should be
aware of the incoming data and manually mask it.
Keeping with a hardcoded list discourages use of the function.
__
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