Re: [Openstack-operators] [openstack-dev] LTS pragmatic example
On 14/11/17 22:33 +1100, Davanum Srinivas wrote: Saverio, This is still under the stable team reviews... NOT LTS. Your contacts for the Nova Stable team is ... https://review.openstack.org/#/admin/groups/540,members Let's please be clear, we need new people to help with LTS plans. Current teams can't scale, they should not have to and it's totally unfair to expect them to do so. I think you may have misunderstood Saverio's email. IIUC, what he was trying to do was provide an example in favor of the LTS branches as discussed in Sydney, rather than requesting for reviews or suggesting the stable team should do LTS. Flavio On Tue, Nov 14, 2017 at 8:02 PM, Saverio Proto <ziopr...@gmail.com> wrote: Hello, here an example of a trivial patch that is important for people that do operations, and they have to troubleshoot stuff. with the old Stable Release thinking this patch would not be accepted on old stable branches. Let's see if this gets accepted back to stable/newton https://review.openstack.org/#/q/If525313c63c4553abe8bea6f2bfaf75431ed18ea Please note that a developers/operators that make the effort of fixing this in master, should do also all the cherry-pickes back. We dont have any automatic procudure for this. thank you Saverio -- @flaper87 Flavio Percoco signature.asc Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Reminder (1 day left) -- Forum Topic Submission
Hello Everyone, This is a friendly reminder that the submission period ends tomorrow (Sep 29th). Take some time to think about the topics you would like to talk about and submit them at: http://forumtopics.openstack.org/cfp/create Submit your topic before 11:59PM UTC on Friday September 29th! Regards, UC/TC ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [deployment][forum] proposing a session about future of configuration management - ops + devs wanted!
On 21/03/17 18:23 -0400, Emilien Macchi wrote: OpenStack developers and operators who work on deployments: we need you. http://forumtopics.openstack.org/cfp/details/15 Abstract: I would like to bring Developers and Operators in a room to discuss about future of Configuration Management in OpenStack. Until now, we haven't done a good job in collaborating on how we make configuration management in a consistent way across OpenStack Deployment Tools. Some efforts started to emerge in Pike: https://etherpad.openstack.org/p/deployment-pike And some projects like TripleO started some discussion on future of configuration management: https://etherpad.openstack.org/p/tripleo-etcd-transition In this discussion, we will discuss about our common challenges and take some actions from there, where projects could collaborate. Desired people: - Folks from Deployment Tools (TripleO, Kolla, OSA, Kubernetes, etc) - Operators who deploy OpenStack Moderator: me + any volunteer. Happy to help moderating and/or working on the content. Flavio Any question on this proposal is very welcome by using this thread. Thanks for reading so far and I'm looking forward to making progress on this topic in Boston. -- 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 -- @flaper87 Flavio Percoco signature.asc Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [glance] glance-registry deprecation: Request for feedback
On 13/05/16 17:10 -0400, Nikhil Komawar wrote: On 5/13/16 4:29 PM, Flavio Percoco wrote: On 13/05/16 15:52 -0400, Nikhil Komawar wrote: On 5/13/16 3:36 PM, Flavio Percoco wrote: On 12/05/16 21:41 -0400, Nikhil Komawar wrote: I have been of the same opinion as far as upgrades go. I think we are stepping ahead of ourselves here a bit. We need to figure out the rolling upgrade story first and see if registry is actually useful or not there as well. I kinda disagree, tbh. We can have a glance-api service that can be upgraded with no downtimes without the need of a registry service. With a oslo.vo implementation to work with different models of Glance tables (image/members/etc.) schema you _need_ a service that can talk to both the type of the models without having to upgrade the DB. From my initial perspective, the API nodes up-gradation process will not help when we use oslo.vo. Because the API will need to be capable of using the new schema where as the DB still has a old one. What is the current thought process for supporting a rolling upgrade for DB? Why? I'm failing to see the need of a separate service to do this. The above I do not know all the answers hence, the request for research. For instance: * What happens if I have 3 g-api nodes (no-registry) and oslo.vo upgrade support for the DB. The oslo.vo code you'd use for glance-registry would be the exact same you would use for glance-api because they both share the same database code. Therefore, once the oslo.vo code will be implemented, it'd work the same way for the registry service as it'd for the api node. Shutting down all registry nodes to upgrade the DB is not rolling upgrades and it'll cause a downtime. Whatever solution we're thinking to use to fix the registry upgrade issues, we should be able to use for the api service. (I know you know this, just stating for the sake of discussion) * If I upgrade first g-api do a PATCH on an image (that updates the DB'dOA scheme), and then go GET via the other 2 g-api (older version of the g-api) on the same image. What should the non-upgraded g-api return? The older version of that object. A change to the database schema does not translate to a change in the API. It could, sometimes, but not always. Talking specifically about changes to the *API*, the user would get an older response and I don't think that's really an issue. You could also upgrade a set of glance-api nodes and once those are back up redirect the trafic there while the rest of the nodes are upgraded. That should avoid most of the cases like the one you mentioned above. suggests there's a service that exposes a single API and that is also capable of talking to both database schemas. Why can't that service be glance-api itself? Whatever transformation happens in this separate service could as well happen in the main service. What am I missing? I think we need to define some usage patterns and the upgrade support for them to be definite in our approach. Agreed! The point I'm trying to make, however, is that we don't need the registry to have rolling upgrades. Flavio -- @flaper87 Flavio Percoco signature.asc Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [glance] glance-registry deprecation: Request for feedback
On 13/05/16 15:52 -0400, Nikhil Komawar wrote: On 5/13/16 3:36 PM, Flavio Percoco wrote: On 12/05/16 21:41 -0400, Nikhil Komawar wrote: I have been of the same opinion as far as upgrades go. I think we are stepping ahead of ourselves here a bit. We need to figure out the rolling upgrade story first and see if registry is actually useful or not there as well. I kinda disagree, tbh. We can have a glance-api service that can be upgraded with no downtimes without the need of a registry service. With a oslo.vo implementation to work with different models of Glance tables (image/members/etc.) schema you _need_ a service that can talk to both the type of the models without having to upgrade the DB. From my initial perspective, the API nodes up-gradation process will not help when we use oslo.vo. Because the API will need to be capable of using the new schema where as the DB still has a old one. What is the current thought process for supporting a rolling upgrade for DB? Why? I'm failing to see the need of a separate service to do this. The above suggests there's a service that exposes a single API and that is also capable of talking to both database schemas. Why can't that service be glance-api itself? Whatever transformation happens in this separate service could as well happen in the main service. What am I missing? Flavio The feedback from operator sessions also indicated that some ops do use it that way ( http://lists.openstack.org/pipermail/openstack-dev/2016-May/094034.html ). Overall, I do think registry is a bit of overhead and it would be nice to actually deprecate it but we do need facts/technical research first. On 5/12/16 9:20 PM, Sam Morrison wrote: We find glance registry quite useful. Have a central glance-registry api is useful when you have multiple datacenters all with glance-apis and talking back to a central registry service. I guess they could all talk back to the central DB server but currently that would be over the public Internet for us. Not really an issue, we can work around it. The major thing that the registry has given us has been rolling upgrades. We have been able to upgrade our registry first then one by one upgrade our API servers (we have about 15 glance-apis) I'm curious to know how you did this upgrade, though. Did you shutdown your registry nodes, upgraded the database and then re-started them? Did you upgraded one registry node at a time? I'm asking because, as far as I can tell, the strategy you used for upgrading the registry nodes is the one you would use to upgrade the glance-api nodes today. Shutting down all registry nodes would live you with unusable glance-api nodes anyway so I'd assume you did a partial upgrade or something similar to that. Thanks a bunch for your feedback, Flavio I don’t think we would’ve been able to do that if all the glance-apis were talking to the DB, (At least not in glance’s current state) Sam On 12 May 2016, at 1:51 PM, Flavio Percoco <fla...@redhat.com> wrote: Greetings, The Glance team is evaluating the needs and usefulness of the Glance Registry service and this email is a request for feedback from the overall community before the team moves forward with anything. Historically, there have been reasons to create this service. Some deployments use it to hide database credentials from Glance public endpoints, others use it for scaling purposes and others because v1 depends on it. This is a good time for the team to re-evaluate the need of these services since v2 doesn't depend on it. So, here's the big question: Why do you think this service should be kept around? Summit etherpad: https://etherpad.openstack.org/p/newton-glance-registry-deprecation Flavio -- @flaper87 Flavio Percoco ___ 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 -- Thanks, Nikhil -- Thanks, Nikhil -- @flaper87 Flavio Percoco signature.asc Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [glance] glance-registry deprecation: Request for feedback
On 12/05/16 21:41 -0400, Nikhil Komawar wrote: I have been of the same opinion as far as upgrades go. I think we are stepping ahead of ourselves here a bit. We need to figure out the rolling upgrade story first and see if registry is actually useful or not there as well. I kinda disagree, tbh. We can have a glance-api service that can be upgraded with no downtimes without the need of a registry service. The feedback from operator sessions also indicated that some ops do use it that way ( http://lists.openstack.org/pipermail/openstack-dev/2016-May/094034.html ). Overall, I do think registry is a bit of overhead and it would be nice to actually deprecate it but we do need facts/technical research first. On 5/12/16 9:20 PM, Sam Morrison wrote: We find glance registry quite useful. Have a central glance-registry api is useful when you have multiple datacenters all with glance-apis and talking back to a central registry service. I guess they could all talk back to the central DB server but currently that would be over the public Internet for us. Not really an issue, we can work around it. The major thing that the registry has given us has been rolling upgrades. We have been able to upgrade our registry first then one by one upgrade our API servers (we have about 15 glance-apis) I'm curious to know how you did this upgrade, though. Did you shutdown your registry nodes, upgraded the database and then re-started them? Did you upgraded one registry node at a time? I'm asking because, as far as I can tell, the strategy you used for upgrading the registry nodes is the one you would use to upgrade the glance-api nodes today. Shutting down all registry nodes would live you with unusable glance-api nodes anyway so I'd assume you did a partial upgrade or something similar to that. Thanks a bunch for your feedback, Flavio I don’t think we would’ve been able to do that if all the glance-apis were talking to the DB, (At least not in glance’s current state) Sam On 12 May 2016, at 1:51 PM, Flavio Percoco <fla...@redhat.com> wrote: Greetings, The Glance team is evaluating the needs and usefulness of the Glance Registry service and this email is a request for feedback from the overall community before the team moves forward with anything. Historically, there have been reasons to create this service. Some deployments use it to hide database credentials from Glance public endpoints, others use it for scaling purposes and others because v1 depends on it. This is a good time for the team to re-evaluate the need of these services since v2 doesn't depend on it. So, here's the big question: Why do you think this service should be kept around? Summit etherpad: https://etherpad.openstack.org/p/newton-glance-registry-deprecation Flavio -- @flaper87 Flavio Percoco ___ 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 -- Thanks, Nikhil -- @flaper87 Flavio Percoco signature.asc Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [glance] glance-registry deprecation: Request for feedback
Greetings, The Glance team is evaluating the needs and usefulness of the Glance Registry service and this email is a request for feedback from the overall community before the team moves forward with anything. Historically, there have been reasons to create this service. Some deployments use it to hide database credentials from Glance public endpoints, others use it for scaling purposes and others because v1 depends on it. This is a good time for the team to re-evaluate the need of these services since v2 doesn't depend on it. So, here's the big question: Why do you think this service should be kept around? Summit etherpad: https://etherpad.openstack.org/p/newton-glance-registry-deprecation Flavio -- @flaper87 Flavio Percoco signature.asc Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [glance] Summit sessions brainstorm
Greetings, Hey Folks, Now that RC1 is out (YAY!), we should start looking forward to Glance's Newton plans. More specifically, I'd like us to speed up our brainstorm on summit topics. I've set up an etherpad for it and we've got some interesting topics listed already. But there's more, there can be more! I would like to recommend folks to keep in mind what the Mitaka priorities were[0] and that most of this priorities will likely be adopted in Newton as well. While it's awesome to have many sessions (and especially diverse sessions) I believe it's better for Glance if we would keep most of them focused on what the priorities for the next summit are/will be/could be. We'll start discussing these sessions in our next meeting (Thursday March, 24th). Here's the link to the etherpad: https://etherpad.openstack.org/p/newton-glance-summit-planning [0] http://specs.openstack.org/openstack/glance-specs/priorities/mitaka-priorities.html Cheers, Flavio -- @flaper87 Flavio Percoco signature.asc Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [glance] Remove `run_tests.sh` and `tools/*`
On 04/03/16 14:12 -0500, Nikhil Komawar wrote: Surely you can directly use the standard libraries to test systemwide but I am more curious to know if there are some who are still using run_tests wrappings that exist for to ease the pain a bit. Oh, sorry if I came off wrong. What I meant is that if you have glance installed systemwide, you'd be better off running the command found in tox.ini rather than running `run_tests.sh`. One reason is that one point in favor to `tox` and even `run_tests.sh` itself is isolating test environments. Other than that, I don't think they provide much other benefits over just running testr directly (which I sometimes do). Hope that's clearer, Flavio On 3/4/16 12:41 PM, Flavio Percoco wrote: On 04/03/16 11:59 -0500, Nikhil Komawar wrote: I think the hard question to me here is: Do people care about testing code on system installs vs. virtual env? run_tests does that and for some cases when you want to be extra sure about your CICD nodes, packaging and upgrades, the problem is solved. Are packagers using tox to this purpose? TBH, if you're testing things without venvs and sytemwide, I think it'd be far easier to just call nosetests/testr directly in your system than calling the run_tests script. Some packages don't even ship tests. Cheers, Flavio On 3/4/16 11:16 AM, Steve Martinelli wrote: The keystone team did the same during Liberty while we were moving towards using oslo.* projects instead of oslo-incubator [0]. We also noticed that they were rarely used, and we did not go through a deprecation process since these are developer tools. We're still finding a few spots in our docs that need updating, but overall it was an easy transition. [0] https://github.com/openstack/keystone/commit/55e9514cbd4e712e2c317335294355cf1596d870 stevemar Inactive hide details for Flavio Percoco ---2016/03/04 06:51:47 AM---Hey Folks, I'm looking at doing some cleanups in our repo Flavio Percoco ---2016/03/04 06:51:47 AM---Hey Folks, I'm looking at doing some cleanups in our repo and I would like to start by From: Flavio Percoco <fla...@redhat.com> To: openstack-...@lists.openstack.org Cc: openstack-operators@lists.openstack.org Date: 2016/03/04 06:51 AM Subject: [Openstack-operators] [glance] Remove `run_tests.sh` and `tools/*` Hey Folks, I'm looking at doing some cleanups in our repo and I would like to start by deprecating the `run_tests` script and the contents in the `tools/` dir. As far as I can tell, no one is using this code - we're not even using it in the gate - as it was broken until recently, I believe. The recommended way to run tests is using `tox` and I believe having this script in the code base misleads new contributors and other users. So, before we do this. I wanted to get feedback from a broader audience and give a heads up to folks that might be using this code. Any objections? Something I'm missing? Flavio -- @flaper87 Flavio Percoco [attachment "signature.asc" deleted by Steve Martinelli/Toronto/IBM] ___ 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 -- Thanks, Nikhil -- Thanks, Nikhil -- @flaper87 Flavio Percoco signature.asc Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [glance] Remove `run_tests.sh` and `tools/*`
Hey Folks, I'm looking at doing some cleanups in our repo and I would like to start by deprecating the `run_tests` script and the contents in the `tools/` dir. As far as I can tell, no one is using this code - we're not even using it in the gate - as it was broken until recently, I believe. The recommended way to run tests is using `tox` and I believe having this script in the code base misleads new contributors and other users. So, before we do this. I wanted to get feedback from a broader audience and give a heads up to folks that might be using this code. Any objections? Something I'm missing? Flavio -- @flaper87 Flavio Percoco signature.asc Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Downgrade in Trove
On 03/12/15 12:08 +, Telles Nobrega wrote: Hello all, we from Trove, want to remove the downgrade fuctionality from our SQL Schema. This was a TC approved spec for all projects across OpenStack[1] and we need to follow this process as well. We would like to know if are there anyone using this functionality and that removing it would be a complete mess up for your environment. If anyone here is against this please speak up, we are gonna wait 48h and if we get no negative response we will move forward and remove downgrade. Hey Telles, It's always recommended to wait for a bit more than 48h (1 week?). That being said, we (Glance) moved forward with this by adding first a deprecation warning on downgrades and deferring the deletion to N so that OPs that are actually using it (no idea if there are) can move away from it. Flavio Thanks in advance, [1] http://specs.openstack.org/openstack/openstack-specs/specs/ no-downward-sql-migration.html -- Telles Nobrega Software Engineer @ Red Hat ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators -- @flaper87 Flavio Percoco ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Adding v1 LIKE support to python-glanceclient releases 1.x.x
On 09/09/15 21:46 -0400, Clayton O'Neill wrote: I'd be glad to see the backwards compatibility parts go in. I got bitten by this earlier this week and ended up switching my scripts over to using the python-openstackclient library to work around it. Hey Clayton, Thanks for the feedback. Could you be more precise on what incompatibility affected you? The patch that Nikhil linked in his email brings in several "compatibilities" with v1. I personally think they should be examined 1 by 1 rather than pulling them all in, hence my question. Switching to python-openstack client must have required some effort and I'm curious to know why you decided to do that rather than adapting your scripts to use the v2 cli. Do you have Glance's v2 deployed? Ideally, I think we should just move to use openstackclient, really. But glanceclient is what we have now and that's what the Glance team has focused on the most lately so I'd appreaciate as much feedback as possible from you and others. Thanks for your time, Flavio On Wed, Sep 9, 2015 at 6:41 PM, Nikhil Komawar <nik.koma...@gmail.com> wrote: Hi all, We recently release python-glanceclient 1.0.0 and it has the default shell version as v2. This may result into some scripts not detecting the change by default and discomfort to an extent. So, I am reaching out to this list with the hope of getting some feedback on the requirements, pros and cons you all think exist for adding some support for v1 like calls as hidden command to the default python-glanceclient shell API that is v2 centric by default. This should unbreak the scripts to an extent and give a warning to users to update the scripts in a stipulated time period so that they use the v2 API. Here's the proposed patch https://review.openstack.org/#/c/219802/ . We are not yet sure if we need to get it merged by tomorrow so that it can be in stable/liberty by the end of the week. There has been one request to get those in and the feedback we received from the developer community was neutral. In order to form an opinion on what's best for our users, we need some feedback on this topic. Please send us your thoughts as soon as possible and we will try to accommodate the same if permissible within the technical limitations: 1. Whether you would like these commands added as hidden commands so that shell API works like before (to extent possible). 2. You would like to use v2 shell API of the client by default and don't care about this commit. 3. You don't care about the change. Your scripts are awesome and can adjust to the upgrade of the client easily. 4. Anything else. -- Thanks, Nikhil ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators -- @flaper87 Flavio Percoco pgpdHvfcNV6Cq.pgp Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [glance] Removal of Catalog Index Service from Glance
On 27/07/15 19:24 +, Ian Cordasco wrote: On 7/27/15, 11:29, Louis Taylor lo...@kragniz.eu wrote: On Fri, Jul 17, 2015 at 07:50:55PM +0100, Louis Taylor wrote: Hi operators, In Kilo, we added the Catalog Index Service as an experimental API in Glance. It soon became apparent this would be better suited as a separate project, so it was split into the Searchlight project: https://wiki.openstack.org/wiki/Searchlight We've now started the process of removing the service from Glance for the Liberty release. Since the service was originally had the status of being experimental, we felt it would be okay to remove it without a cycle of deprecation. Is this something that would cause issues for any existing deployments? If you have any feelings about this one way or the other, feel free to share your thoughts on this mailing list or in the review to remove the code: https://review.openstack.org/#/c/197043/ Some time has passed and no one has complained about this, so I propose we go ahead and remove it in liberty. Cheers, Louis +1 Commented on the review! +2 __ 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 -- @flaper87 Flavio Percoco pgp27Jqj0N95q.pgp Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [Glance] [glance_store] Feedback requested from users of the HTTP Store
On 12/06/15 02:31 +, Ian Cordasco wrote: Hey all, For the Liberty development cycle, I've proposed a specification for a refactor of Glance's HTTP Store - https://review.openstack.org/#/c/189537/. In short, currently Glance's HTTP Store driver does not verify HTTPS connections. This allows for a couple of attacks of varying severity. We had a short discussion in our meeting yesterday (http://eavesdrop.openstack.org/meetings/glance/2015/glance.2015-06-11-14.0 0.log.html) and one person suggested that the new configuration options being proposed should default to insecure. If we decide to make them insecure as a default this will make upgrades much easier on operators but will mean that protection against the attacks described will be opt-in, at least for one cycle. So, I'm asking for your feedback because this is really intended to benefit you. Are you using the HTTP store? Are you serving your images over HTTPS? Would you be in favor of turning HTTPS verification on by default? Why or why not? Can we just add it as insecure for a couple of releases (or just one) w/ a warning saying that it'll be changed to secure? This won't take that much work out of OPs since it'll be required to update the config anyway but at least it'll give enough time and it'll allow for gradual updates. Thanks for working on this, Ian. Flavio -- @flaper87 Flavio Percoco pgp5hdaPHmvuF.pgp Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
