[Openstack] IMPORTANT: This list is retired
This mailing list was replaced by a new openstack-disc...@lists.openstack.org mailing list[0] as of Monday November 19, 2018 and starting now will no longer receive any new messages. The archive of prior messages will remain published in the expected location indefinitely for future reference. For convenience posts to the old list address will be rerouted to the new list for an indeterminate period of time, but please correct it in your replies if you notice this. See my original notice[1] (and the many reminders sent in months since) for an explanation of this change. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack/2018-September/047005.html -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] IMPORTANT: We're combining the lists!
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list[0] has been open for posts from subscribers since Monday November 19, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 403 subscribers on openstack-discuss with six days to go before the old lists are closed down for good). I have updated the old list descriptions to indicate the openstack-discuss list is preferred, and added a custom "welcome message" with the same for anyone who subscribes to them over the next week. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature ___ 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
[Openstack] IMPORTANT: We're combining the lists!
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list[0] is open for posts from subscribers starting now, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 280 subscribers on openstack-discuss with three weeks to go before the old lists are closed down for good). At the recommendation of David Medberry at the OpenStack Summit last week, this reminder is being sent individually to each of the old lists (not as a cross-post), and without any topic tag in case either might be resulting in subscribers missing it. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] [openstack-dev] [all] We're combining the lists!
On 2018-11-10 11:02:15 +0100 (+0100), Thierry Carrez wrote: [...] > As we are ultimately planning to move lists to mailman3 (which decided > to drop the "topics" concept altogether), I don't think we planned to > add serverside mailman topics to the new list. Correct, that was covered in more detail in the longer original announcement linked from my past couple of reminders: http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html In short, we're recommending client-side filtering because server-side topic selection/management was not retained in Mailman 3 as Thierry indicates and we hope we might move our lists to an MM3 instance sometime in the not-too-distant future. > We'll still have standardized subject line topics. The current list > lives at: > > https://etherpad.openstack.org/p/common-openstack-ml-topics Which is its initial location for crowd-sourcing/brainstorming, but will get published to a more durable location like on lists.openstack.org itself or perhaps the Project-Team Guide once the list is in use. -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] [all] We're combining the lists!
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this is being sent) will be replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list is open for subscriptions[0] now, but is not yet accepting posts until Monday November 19 and it's strongly recommended to subscribe before that date so as not to miss any messages posted there. The old lists will be configured to no longer accept posts starting on Monday December 3, but in the interim posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them any time after the 19th and not miss any messages. See my previous notice[1] for details. For those wondering, we have 207 subscribers so far on openstack-discuss with a little over a week to go before it will be put into use (and less than a month before the old lists are closed down for good). [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] [openstack client] command completion
On 2018-11-06 10:58:04 +0900 (+0900), Bernd Bausch wrote: [...] > By the way, there used to be a /python-openstackclient /section in > Launchpad. Doesn't exist anymore. Where are bugs tracked these days? At the top of https://launchpad.net/python-openstackclient it says, "Note that all Launchpad activity (just bugs & blueprints really) has been migrated to OpenStack's Storyboard: https://storyboard.openstack.org/#!/project_group/80"; I suppose now that project group name URL support is in for SB, they could update that to the more memorable https://storyboard.openstack.org/#!/project_group/openstackclient instead. -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] [all] We're combining the lists! (was: Bringing the community together...)
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this is being sent) will be replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list is open for subscriptions[0] now, but is not yet accepting posts until Monday November 19 and it's strongly recommended to subscribe before that date so as not to miss any messages posted there. The old lists will be configured to no longer accept posts starting on Monday December 3, but in the interim posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them any time after the 19th and not miss any messages. See my previous notice[1] for details. For those wondering, we have 127 subscribers so far on openstack-discuss with 3 weeks to go before it will be put into use (and 5 weeks now before the old lists are closed down for good). [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] non public glance image can seen by all tenant
On 2018-10-26 11:29:27 +0700 (+0700), Adhi Priharmanto wrote: > I have setup rocky release at my openstack lab, now all of tenant > (user) can see non-public glance image create by another tenant > (user) [...] This sounds very similar to https://launchpad.net/bugs/1799588 which the Glance team has been asked to look into. See also the rather lengthy troubleshooting discussion on the Operators ML starting here: http://lists.openstack.org/pipermail/openstack-operators/2018-October/016039.html -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] [openstack] openstack setups at Universities
On 2018-10-10 02:54:52 +0200 (+0200), Jay See wrote: > May be a different question , not completely related to issues > associated with openstack. > > Does anyone know any university or universities using opnstack for > cloud deployment and resource sharing. There are many, but the first which comes to mind for me is the Massachusetts Institute of Technology: https://tig.csail.mit.edu/shared-computing/open-stack/ -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] [Openstack-sigs] Capturing Feedback/Input
On 2018-09-21 12:55:09 -0500 (-0500), Melvin Hillsman wrote: [...] > Yeah unfortunately we do have a tendency to overthink/complicate > things. Not saying Storyboard is the right tool but suggested > rather than having something extra to maintain was what I > understood. There are at least 3 things that were to be addressed: > > - single pane so folks know where to provide/see updates Not all OpenStack projects use the same task trackers currently and there's no guarantee that they ever will, so this is a best effort only. Odds are you may wind up duplicating some information also present in the Nova project on Launchpad, the Tripleo project on Trello and the Foobly project on Bugzilla (I made this last one up, in case it's not obvious). > - it is not a catchall/dumpsite If it looks generic enough, it will become that unless there are people actively devoted to triaging and pruning submissions to curate them... a tedious and thankless long-term commitment, to be sure. > - something still needs to be flushed out/prioritized (Public > Cloud WG's missing features spreadsheet for example) This is definitely a good source of input, but still needs someone to determine which various projects/services the tasks for them get slotted into and then help prioritizing and managing spec submissions on a per-team basis. > - not specific to a single project (i thought this was a given > since there is already a process/workflow for single project) The way to do that on storyboard.openstack.org is to give it a project of its own. Basically just couple it to a new, empty Git repository and then the people doing these tasks still have the option of also putting that repository to some use later (for example, to house their workflow documentation). > I could very well be wrong so I am open to be corrected. From my > perspective the idea in the room was to not circumvent anything > internal but rather make it easy for external viewers, passerbys, > etc. When feedback is gathered from Ops Meetup, OpenStack Days, > Local meetups/events, we discussed putting that here as well. It seems a fine plan, just keep in mind that documenting and publishing feedback doesn't magically translate into developers acting on any of it (and this is far from the first time it's been attempted). -- Jeremy Stanley signature.asc Description: PGP signature ___ 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
[Openstack] [all] We're combining the lists! (was: Bringing the community together...)
simply auto-subscribe everyone from the four older lists to the new one and call it a day? Well, I personally would find it rude if a list admin mass-subscribed me to a mailing list I hadn't directly requested. Doing so may even be illegal in some jurisdictions (we could probably make a case that it's warranted, but it's cleaner to not need to justify such an action). Much like the answer to the previous question, the changes in behavior (and also in the list name itself) are likely to cause lots of subscribers to need to update their message filtering rules anyway. I know by default it would all start landing in my main inbox, and annoy me mightily. What subject tags are we going to be using to identify messages of interest and to be able to skip those we don't care about? We're going to continuously deploy a list of recommended subject tags in a visible space, either on the listserv's WebUI or the Infra Manual and link to it liberally. There is already an initial set of suggestions[5] being brainstormed, so feel free to add any there you feel might be missing. It's not yet been decided whether we'll also include these in the Mailman "Topics" configuration to enable server-side filtering on them (as there's a good chance we'll be unable to continue supporting that after an upgrade to Mailman 3), so for now it's best to assume you may need to add them to your client-side filters if you rely on that capability. If you have any further questions, please feel free to respond to this announcement so we can make sure they're answered. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-sigs/2018-August/000493.html [2] http://lists.openstack.org/pipermail/openstack-dev/2018-August/134074.html [3] https://etherpad.openstack.org/p/infra-ptg-denver-2018 [4] https://www.ietf.org/rfc/rfc2369.txt [5] https://etherpad.openstack.org/p/common-openstack-ml-topics -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] [Magnum] no documentation for openstack client commands
On 2018-09-13 13:32:27 + (+), Jeremy Stanley wrote: > On 2018-09-13 15:27:51 +0900 (+0900), Bernd Bausch wrote: > [...] > > To add insult to injury, when I click on the bug icon of the user > > guide page, I am told "Launchpad doesn't know what bug tracker > > Magnum uses. ". > [...] > > At the top of https://launchpad.net/magnum it states "Note: Please > file bugs in https://storyboard.openstack.org"; (the last time I > looked, it was still not possible to indicate arbitrary defect > trackers from the bugs sub-pages in LP, only certain trackers the > developers of LP decided to build integration for). It might be a > little more user-friendly if they at least linked > https://storyboard.openstack.org/#!/project/openstack/magnum instead > of the base URL for SB on that main project page, but hopefully it's > enough for most people to find what they're looking for. And yes, it does appear from the results of `git grep -i launchpad` in the openstack/magnum repo that they have quite a few places (contributing, readme, docs index...) where they need to update the URL for defect reporting to no longer be on launchpad.net. -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] [Magnum] no documentation for openstack client commands
On 2018-09-13 15:27:51 +0900 (+0900), Bernd Bausch wrote: [...] > To add insult to injury, when I click on the bug icon of the user > guide page, I am told "Launchpad doesn't know what bug tracker > Magnum uses. ". [...] At the top of https://launchpad.net/magnum it states "Note: Please file bugs in https://storyboard.openstack.org"; (the last time I looked, it was still not possible to indicate arbitrary defect trackers from the bugs sub-pages in LP, only certain trackers the developers of LP decided to build integration for). It might be a little more user-friendly if they at least linked https://storyboard.openstack.org/#!/project/openstack/magnum instead of the base URL for SB on that main project page, but hopefully it's enough for most people to find what they're looking for. -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] [all] Bringing the community together (combine the lists!)
On 2018-08-31 14:02:23 +0200 (+0200), Thomas Goirand wrote: [...] > I'm coming from the time when OpenStack had a list on launchpad > where everything was mixed. We did the split because it was really > annoying to have everything mixed. [...] These days (just running stats for this calendar year) we've been averaging 4 messages a day on the general openstack@lists.o.o ML, so if it's volume you're worried about most of it would be the current -operators and -dev ML discussions anyway (many of which are general questions from users already, because as you also pointed out we don't usually tell them to take their questions elsewhere any more). -- Jeremy Stanley signature.asc Description: PGP signature ___ 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
[Openstack] Mailman topic filtering (was: Bringing the community together...)
On 2018-08-31 09:35:55 +0100 (+0100), Stephen Finucane wrote:
[...]
> I've tinked with mailman 3 before so I could probably take a shot at
> this over the next few week(end)s; however, I've no idea how this
> feature is supposed to work. Any chance an admin of the current list
> could send me a couple of screenshots of the feature in mailman 2 along
> with a brief description of the feature? Alternatively, maybe we could
> upload them to the wiki page Tony linked above or, better yet, to the
> technical details page for same:
>
> https://wiki.mailman.psf.io/DEV/Brief%20Technical%20Details
Looks like this should be
https://wiki.list.org/DEV/Brief%20Technical%20Details instead,
however reading through it doesn't really sound like the topic
filtering feature from MM2.
The List Member Manual has a very brief description of the feature
from the subscriber standpoint:
http://www.list.org/mailman-member/node29.html
The List Administration Manual unfortunately doesn't have any
content for the feature, just a stubbed-out section heading:
http://www.list.org/mailman-admin/node30.html
Sending screenshots to the ML is a bit tough, but luckily MIT's
listadmins have posted some so we don't need to:
http://web.mit.edu/lists/mailman/topics.html
--
Jeremy Stanley
signature.asc
Description: PGP signature
___
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] [Openstack-sigs] [Openstack-operators] [openstack-dev] [all] Bringing the community together (combine the lists!)
On 2018-08-30 18:08:56 -0500 (-0500), Melvin Hillsman wrote: [...] > I also recall us discussing having some documentation or way of > notifying net new signups of how to interact with the ML > successfully. An example was having some general guidelines around > tagging. Also as a maintainer for at least one of the mailing > lists over the past 6+ months I have to inquire about how that > will happen going forward which again could be part of this > documentation/initial message. [...] Mailman supports customizable welcome messages for new subscribers, so the *technical* implementation there is easy. I do think (and failed to highlight it explicitly earlier I'm afraid) that this proposal comes with an expectation that we provide recommended guidelines for mailing list use/etiquette appropriate to our community. It could be contained entirely within the welcome message, or merely linked to a published document (and whether that's best suited for the Infra Manual or New Contributor Guide or somewhere else entirely is certainly up for debate), or even potentially both. -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] [Openstack-operators] [openstack-dev] [all] Bringing the community together (combine the lists!)
On 2018-08-30 22:49:26 +0200 (+0200), Thomas Goirand wrote: [...] > I really don't want this. I'm happy with things being sorted in > multiple lists, even though I'm subscribed to multiples. I understand where you're coming from, and I used to feel similarly. I was accustomed to communities where developers had one mailing list, users had another, and whenever a user asked a question on the developer mailing list they were told to go away and bother the user mailing list instead (not even a good, old-fashioned "RTFM" for their trouble). You're probably intimately familiar with at least one of these communities. ;) As the years went by, it's become apparent to me that this is actually an antisocial behavior pattern, and actively harmful to the user base. I believe OpenStack actually wants users to see the development work which is underway, come to understand it, and become part of that process. Requiring them to have their conversations elsewhere sends the opposite message. -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] [openstack-dev] [all] Bringing the community together (combine the lists!)
On 2018-08-30 12:57:31 -0600 (-0600), Chris Friesen wrote: [...] > Do we want to merge usage and development onto one list? That > could be a busy list for someone who's just asking a simple usage > question. A counterargument though... projecting the number of unique posts to all four lists combined for this year (both based on trending for the past several years and also simply scaling the count of messages this year so far based on how many days are left) comes out roughly equal to the number of posts which were made to the general openstack mailing list in 2012. > Alternately, if we are going to merge everything then why not just > use the "openstack" mailing list since it already exists and there > are references to it on the web. This was an option we discussed in the "One Community" forum session as well. There seemed to be a slight preference for making a new -disscuss list and retiring the old general one. I see either as an potential solution here. > (Or do you want to force people to move to something new to make them > recognize that something has changed?) That was one of the arguments made. Also I believe we have a *lot* of "black hole" subscribers who aren't actually following that list but whose addresses aren't bouncing new posts we send them for any of a number of possible reasons. -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] [Openstack-sigs] [all] Bringing the community together (combine the lists!)
On 2018-08-31 01:13:58 +0800 (+0800), Rico Lin wrote: [...] > What needs to be done for this is full topic categories support > under `options` page so people get to filter emails properly. [...] Unfortunately, topic filtering is one of the MM2 features the Mailman community decided nobody used (or at least not enough to warrant preserving it in MM3). I do think we need to be consistent about tagging subjects to make client-side filtering more effective for people who want that, but if we _do_ want to be able to upgrade we shouldn't continue to rely on server-side filtering support in Mailman unless we can somehow work with them to help in reimplementing it. -- Jeremy Stanley signature.asc Description: PGP signature ___ 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
[Openstack] [all] Bringing the community together (combine the lists!)
The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists on lists.openstack.org see an increasing amount of cross-posting and thread fragmentation as conversants attempt to reach various corners of our community with topics of interest to one or more (and sometimes all) of those overlapping groups of subscribers. For some time we've been discussing and trying ways to bring our developers, distributors, operators and end users together into a less isolated, more cohesive community. An option which keeps coming up is to combine these different but overlapping mailing lists into one single discussion list. As we covered[1] in Vancouver at the last Forum there are a lot of potential up-sides: 1. People with questions are no longer asking them in a different place than many of the people who have the answers to those questions (the "not for usage questions" in the openstack-dev ML title only serves to drive the wedge between developers and users deeper). 2. The openstack-sigs mailing list hasn't seem much uptake (an order of magnitude fewer subscribers and posts) compared to the other three lists, yet it was intended to bridge the communication gap between them; combining those lists would have been a better solution to the problem than adding yet another turned out to be. 3. At least one out of every ten messages to any of these lists is cross-posted to one or more of the others, because we have topics that span across these divided groups yet nobody is quite sure which one is the best venue for them; combining would eliminate the fragmented/duplicative/divergent discussion which results from participants following up on the different subsets of lists to which they're subscribed, 4. Half of the people who are actively posting to at least one of the four lists subscribe to two or more, and a quarter to three if not all four; they would no longer be receiving multiple copies of the various cross-posts if these lists were combined. The proposal is simple: create a new openstack-discuss mailing list to cover all the above sorts of discussion and stop using the other four. As the OpenStack ecosystem continues to mature and its software and services stabilize, the nature of our discourse is changing (becoming increasingly focused with fewer heated debates, distilling to a more manageable volume), so this option is looking much more attractive than in the past. That's not to say it's quiet (we're looking at roughly 40 messages a day across them on average, after deduplicating the cross-posts), but we've grown accustomed to tagging the subjects of these messages to make it easier for other participants to quickly filter topics which are relevant to them and so would want a good set of guidelines on how to do so for the combined list (a suggested set is already being brainstormed[2]). None of this is set in stone of course, and I expect a lot of continued discussion across these lists (oh, the irony) while we try to settle on a plan, so definitely please follow up with your questions, concerns, ideas, et cetera. As an aside, some of you have probably also seen me talking about experiments I've been doing with Mailman 3... I'm hoping new features in its Hyperkitty and Postorius WebUIs make some of this easier or more accessible to casual participants (particularly in light of the combined list scenario), but none of the plan above hinges on MM3 and should be entirely doable with the MM2 version we're currently using. Also, in case you were wondering, no the irony of cross-posting this message to four mailing lists is not lost on me. ;) [1] https://etherpad.openstack.org/p/YVR-ops-devs-one-community [2] https://etherpad.openstack.org/p/common-openstack-ml-topics -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] git-review tagging schedule
On 2018-08-22 08:53:26 -0700 (-0700), David van der Bokke wrote: > We are curious about when the next version of git-review will be tagged so > that we can create a debian package release for it. Specifically we want > to pick up the change in > https://git.openstack.org/cgit/openstack-infra/git-review/commit/?id=694f532ca803882d7b3446c31f5fc690e9669042 > before refs/publish is completely removed. I've redirected this to the openstack-in...@lists.openstack.org mailing list where it's more on topic; please continue corresponding there instead and drop openstack@lists.openstack.org from any further replies. Have the Gerrit maintainers indicated what version will drop support for the refs/publish path? Or is the urgency more about silencing the deprecation warning? Looking at the currently merged commits since 1.26.0, I see some which are feature additions so we're likely talking about tagging this as 1.27.0 rather than 1.26.1 (depending on whether dropping the vestigial -c command line option counts as a reason to make it 2.0.0 instead, but I feel like it's probably not warranted). Are there other outstanding changes which are important to get into 1.27.0? At a minimum I think we'll want to get https://review.openstack.org/593670 and its parent change merged so that the release note about -c going away will be included in the release. Anything else? -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] ask.openstack.org down?!
On 2018-07-23 11:28:50 +0200 (+0200), Erdősi Péter wrote: > I got connection refused when trying to open ask.openstack.org. > I've tried it from HBONE (AS 1955) and UPC (AS 6830) networks with > no luck. It wasn't a routing issue. The server's Web service was actually not running. Something seems to have occurred (perhaps hit a race condition bug) around the time of the server's scheduled jobs (log rotation, et cetera) which raised a Django WSGI exception and killed the parent Apache process. Starting Apache again has restored the site to working order. Thanks for reporting! > Can someone investigate or escalate this to the right place? A more appropriate list would have been openstack-in...@lists.openstack.org (Cc'd on my reply). -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] Masakari client error
On 2018-05-16 12:30:47 + (+), Torin Woltjer wrote: [...] > I am using Pike and not Queens so the openstacksdk version 13 is > not available in the repository. Should openstacksdk version 0.13 > still work with Pike [...] OpenStackSDK strives for backwards-compatibility with even fairly ancient OpenStack releases, and is not tied to any particular version of OpenStack services. It should always be safe to run the latest releases of OpenStackSDK no matter the age of the deployment with which you intend to communicate. Note however that the dependencies of OpenStackSDK may conflict with dependencies of some OpenStack service, so you can't necessarily expect to be able to co-install them on the same machine without some means of context separation (virtualenvs, containers, pip install --local, et cetera). -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] which SDK to use?
On 2018-04-19 12:24:48 +1000 (+1000), Joshua Hesketh wrote: > There is also nothing stopping you from using both. For example, > you could use the OpenStack SDK for most things but if you hit an > edge case where you need something specific you can then import > the particular client lib. [...] Or, for that matter, leverage OpenStackSDK's ability to pass arbitrary calls to individual service APIs when you need something not exposed by the porcelain layer. -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] which SDK to use?
On 2018-04-17 15:38:03 +0300 (+0300), Volodymyr Litovka wrote: [...] > 1) Openstack SDK (https://docs.openstack.org/openstacksdk/latest ) > 2) Openstack Clients (https://wiki.openstack.org/wiki/OpenStackClients ) > > The question is which one to use in terms of support Openstack APIs, > development longevity and consistency with Openstack development? [...] The unified OpenStackSDK is intended as a general, flexible yet consistent programming interface for consumers of a variety of OpenStack services and environments, and this is where most of the innovation you seem to be asking about is happening so is probably a much better choice. The various "client libraries" (e.g. python-novaclient, python-cinderclient, et cetera) can also be used to that end, but are mostly for service-to-service communication these days, aren't extremely consistent with each other, and tend to eventually drop support for older OpenStack APIs so if you're going to be interacting with a variety of different OpenStack deployments built on different releases you may need multiple versions of the client libraries (depending on what it is you're trying to do). -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] Openstack neutron with ASR1k
On 2018-02-01 14:58:46 -0500 (-0500), Satish Patel wrote: > Interesting survey but if i am not wrong Fuel is end of life and they > stopped development right? [...] Sure, but that doesn't mean people aren't still running environments deployed with it. -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] Openstack neutron with ASR1k
On 2018-02-01 19:21:03 + (+), Jeremy Stanley wrote: > On 2018-02-01 19:15:51 +0400 (+0400), Fawaz Mohammed wrote: > > TripleO (Supported on CentOS and RHEL) and Juju (Supported on > > Ubuntu) [1] are the most used OpenStack deployment tools. > [...] > > Most used in what sense? That statistic seems to contradict the > results of the official OpenStack User Survey from April 2017 (page > 42) at least, which claims that more deployments used Ansible (45%), > Puppet (28%), Fuel (16%) and Chef (14%) than Juju (9%). TripleO > didn't even have enough responses on that question to rank. > > https://www.openstack.org/assets/survey/April2017SurveyReport.pdf Also, the analytics tool for the later November 2017 survey results gives basically the same ranking though the percentages changed slightly (and Fuel/Chef traded spots). https://www.openstack.org/analytics -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] Openstack neutron with ASR1k
On 2018-02-01 19:15:51 +0400 (+0400), Fawaz Mohammed wrote: > TripleO (Supported on CentOS and RHEL) and Juju (Supported on > Ubuntu) [1] are the most used OpenStack deployment tools. [...] Most used in what sense? That statistic seems to contradict the results of the official OpenStack User Survey from April 2017 (page 42) at least, which claims that more deployments used Ansible (45%), Puppet (28%), Fuel (16%) and Chef (14%) than Juju (9%). TripleO didn't even have enough responses on that question to rank. https://www.openstack.org/assets/survey/April2017SurveyReport.pdf -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] Openstack manual setup
While not a single-server deployment, the reasoning behind Matt's experiment documented at https://blog.kortar.org/?p=380 (deploying from official release tarballs and following the official install guides) seems similar. You might take some clues from the experiences he describes there. -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] Regarding Openings on Red Hat's Public Sector Team for OpenStack Engineers
On 2018-01-29 07:36:51 -0500 (-0500), Suzie Grieco wrote: > May I request the following to be forwarded to members of your OpenStack > mailing list? [...] In the future, please post OpenStack-related job openings at https://www.openstack.org/community/jobs/ instead of on our discussion lists. Thanks! -- Jeremy Stanley signature.asc Description: PGP signature ___ 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] Fwd: [Openstack-zh] openstack CN domain and keyword
On 2017-12-31 21:51:12 -0800 (-0800), Jerry Xinyu Zhao wrote: > Forward to the general list from Chinese zh mailing list. > People concerned please look into it. [...] Thanks for the heads up, though this looks like a phishing scam (reputable registrars would get in touch with the domain contact listed in the cn TLD whois DB rather than a random discussion mailing list, and the sender's address seems to be at a throw-away domain which doesn't match the more official-looking address in their signature at all). -- Jeremy Stanley signature.asc Description: PGP signature ___ 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
[Openstack] [OSSA-2017-006] Nova FilterScheduler doubles resource allocations during rebuild with new image (CVE-2017-17051)
== OSSA-2017-006: Nova FilterScheduler doubles resource allocations during rebuild with new image == :Date: December 05, 2017 :CVE: CVE-2017-17051 Affects ~~~ - Nova: ==16.0.3 Description ~~~ Matt Riedemann from Huawei reported a vulnerability in OpenStack Nova's default FilterScheduler. By repeatedly rebuilding an instance with new images, an authenticated user may consume untracked resources on a hypervisor host leading to a denial of service. This regression was introduced with the fix for OSSA-2017-005 (CVE-2017-16239), however, only Nova stable/pike or later deployments with that fix applied and relying on the default FilterScheduler are affected. Patches ~~~ - https://review.openstack.org/523214 (Pike) - https://review.openstack.org/521662 (Queens) Credits ~~~ - Matt Riedemann from Huawei (CVE-2017-17051) References ~~ - https://launchpad.net/bugs/1732976 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17051 -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: Digital signature ___ 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] Request to add new Features to Openstack
On 2017-11-05 13:31:18 + (+), Sriram Melukote (c) wrote: > I feel that the following new features should be added into > Openstack:- > > 1) Should create application catalogs for containerizing the > storage of heat templates and other objects. https://docs.openstack.org/murano/ > 2) Should create a key-value store(something like an XDatabase > which stores key-value pairs), to store all certificate related > and other type of information connected to features like > Loadbalancer as a service. https://docs.openstack.org/barbican/ > Please update on these above Feature requests. Can you elaborate on what you feel is missing from the above linked services? It's difficult to determine from your terse message whether you're simply unaware these already exist, or you find them lacking in some way for your particular use case. -- Jeremy Stanley signature.asc Description: Digital signature ___ 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] HKY55303
On 2017-10-06 13:13:15 +0100 (+0100), jer...@openstack.org wrote: > Your statement is attached. Please remit payment at your earliest > convenience. Thank you for your business - we appreciate it very > much. [phishing URL redacted] Wow, obviously I did not send that (and I almost never use the E-mail address it was poorly attempting to pretend to come from). The actual sender's address (anna.osi...@uniwar.pl) doesn't even seem to be subscribed to this list, so I have to assume one of the list moderators accidentally approved the message by mistake. -- Jeremy Stanley signature.asc Description: Digital signature ___ 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] DHCP for IPv6
On 2017-09-28 20:29:38 -0300 (-0300), Jorge Luiz Correa wrote: > It would be good if developers could know about that because > privacy extension is becoming the default on every operate > systems. I've tested last version of *ubuntu and some FreeBSD > kernels, all operating with privacy extension by default. > > So, this way of creating the iptables rules need to be reviewed. [...] To accommodate privacy extensions, we'd basically have to give up on any assumptions as to what the viable source addresses originating on a port could be (at least within the netmask). This filtering is the primary mechanism for preventing address spoofing within a shared network. By comparison, RFC 4941 privacy extensions are primarily a protection for desktop/mobile client systems and do little (if anything) useful for a statically-addressed server. Disabling it there makes a lot of sense to me, as a privacy/security-conscious sysadmin. -- Jeremy Stanley signature.asc Description: Digital signature ___ 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] Hello
On 2017-09-08 11:06:51 +0530 (+0530), Raja Siddharth Raju wrote: > My name is Raja Siddharth Raju, student of Computer Science Engineering > specialization with Cyber Security Forensics under BTech Program 3rd Year. > I wish to contribute to Open Stack Security and would love to be its team > member. I am new to open stack but I have some knowledge about Cyber > Security and web application vulnerabilities which interests me. As a > beginner, what shall be my first steps to explore open cloud. Welcome! One other set of resources nobody seems to have mentioned yet: have a look around https://security.openstack.org/ for our lists of announced vulnerabilities, some of our security-oriented community processes, and summaries of security-related software/tools under development. -- Jeremy Stanley signature.asc Description: Digital signature ___ 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] [Mirantis] How to keep ntpd down
On 2017-07-21 05:56:48 +0530 (+0530), Raja T Nair wrote: [...] > Many other servers sync with this one too. Also only one > controller had issues with time. Kind of stuck here, as I have no > idea why one node's ntpd would fail :( [...] I've seen this from time to time over the years and it's nearly always a bad RTC. Poor quality control is not unusual since the manufacturers assume you either won't care or will use something like NTP to keep things in reasonable sync, but sometimes you'll get one which is well outside your ntpd's tolerance for drift and it'll just flat refuse to update it. In those sorts of situations I've pretty much always sent the server back or requested appropriate replacement parts to service it myself on site. -- Jeremy Stanley signature.asc Description: Digital signature ___ 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
[Openstack] [infra] lists.openstack.org maintenance Friday, May 26 20:00-21:00 UTC
The Mailman listserv on lists.openstack.org will be offline for an archive-related maintenance for up to an hour starting at 20:00 UTC May 26, this coming Friday. This activity is scheduled for a relatively low-volume period across our lists; during this time, most messages bound for the server will queue at the senders' MTAs until the server is back in service and so should not result in any obvious disruption. Apologies for cross-posting so widely, but we wanted to make sure copies of this announcement went to most of our higher-traffic lists. -- Jeremy Stanley signature.asc Description: Digital signature ___ 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] Find core developers
On 2017-04-21 06:22:22 -0700 (-0700), Dariusz Śmigiel wrote: > This information can be retrieved from gerrit. [...] I also wrote a script to build transitive sets of core reviewers for all Git repositories hosted in our code review system, annotated with details from governance when available: http://git.openstack.org/cgit/openstack-infra/system-config/tree/tools/who-approves.py -- Jeremy Stanley ___ 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
[Openstack] [infra] lists.openstack.org maintenance Friday, March 31 20:00-23:00 UTC
The Mailman listserv on lists.openstack.org will be offline for an upgrade-related maintenance for up to 3 hours (but hopefully much less) starting at 20:00 UTC March 31, this coming Friday. This activity is scheduled for a relatively low-volume period across our lists; during this time, most messages bound for the server will queue at the senders' MTAs until the server is back in service and so should not result in any obvious disruption. Apologies for cross-posting so widely, but we wanted to make sure copies of this announcement went to most of our higher-traffic lists. -- Jeremy Stanley signature.asc Description: Digital signature ___ 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] Help with openstack single node deployment
On 2017-03-24 15:53:26 -0600 (-0600), Joe Topjian wrote: > I'm an absolute amateur at this -- no doubt OpenStack Infra has > better tools [...] We don't really have any jobs that operate in the described manner. Instead we test against Mitaka (or any OpenStack release) this way: 1. DevStack is checked-out and built with the desired settings on a single-use virtual machine in a public cloud provider (but there is no public access to that DevStack deployment) 2. Tests are performed from the same virtual machine against the local DevStack running there 3. Results/logs are collected and published by our job scheduler 4. The virtual machine used for that test is deleted and returned to our available quota This is probably a fair amount of extra overhead for your needs, but is done this way in our case because we need to be able to test proposed changes to services running as a part of DevStack and since those get started with root privileges we can't trust the virtual machine for subsequent jobs. Also this has a nice side effect of starting with a fresh, pristine deployment every time for improved consistency. You can read more about the devstack-gate framework we use at http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/README.rst -- Jeremy Stanley ___ 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] Unit Test Error when test servers.py using tox
On 2017-03-24 02:55:39 + (+), Pei Pei2 Jia wrote: > I'm a freshman in openstack. I want to contribute and learn some > exciting by joining openstack. I will be grateful if anyone can > help me on my starting process. You're likely to want to use the openstack-...@lists.openstack.org mailing list for development-related topics, since a lot more of the developer community subscribes to and watches that. > Now I encounter a problem when I tried the UT with tox. > I execute the following command, > > (.venv-nova)[jiapei2@localhost nova]$ tox -e py27 > tests.unit.api.openstack.compute.test_server_action > > And then I got the results: > = > Totals > == > Ran: 136 tests in 51. sec. [...] I'm not an active developer on nova, but I tried to recreate the issue you encountered out of personal curiosity. Unfortunately I don't have a good explanation for it. At least on my workstation (Debian/unstable) with tox 2.5.0 installed from PyPI and a clean checkout of nova's master branch, rerunning `tox -e py27 tests.unit.api.openstack.compute.test_server_action` results in: == Totals == Ran: 66 tests in 41. sec. - Passed: 66 - Skipped: 0 - Expected Fail: 0 - Unexpected Success: 0 - Failed: 0 Sum of execute time for each test: 51.4564 sec. Worth noting, `tox -e bindep` says I'm missing several system packages (graphviz, libsqlite3-dev, mysql-client, mysql-server, postgresql, postgresql-client) which I guess might explain why I only ran 66 tests instead of 136, though the failures you quoted didn't look like they were related to any tests which would have needed those. -- Jeremy Stanley ___ 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
[Openstack] [OSSA-2017-002] Nova logs sensitive context from notification exceptions (CVE-2017-7214)
=== OSSA-2017-002: Nova logs sensitive context from notification exceptions === :Date: March 23, 2017 :CVE: CVE-2017-7214 Affects ~~~ - Nova: >=13.0.0 <=13.1.3, >=14.0.0 <=14.0.4, >=15.0.0 <=15.0.1 Description ~~~ Matt Riedemann with Huawei reported a vulnerability in Nova. Legacy notification exception contexts appearing in ERROR level logs may include sensitive information such as account passwords and authorization tokens. All Nova setups are affected. Patches ~~~ - https://review.openstack.org/447075 (Mitaka) - https://review.openstack.org/447072 (Newton) - https://review.openstack.org/447071 (Ocata) - https://review.openstack.org/446948 (Pike) Credits ~~~ - Matt Riedemann from Huawei (CVE-2017-7214) References ~~ - https://launchpad.net/bugs/1673569 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7214 -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: Digital signature ___ 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
[Openstack] [OSSA-2017-001] CatchErrors leaks sensitive values in oslo.middleware (CVE-2017-2592)
OSSA-2017-001: CatchErrors leaks sensitive values in oslo.middleware :Date: January 26, 2017 :CVE: CVE-2017-2592 Affects ~~~ - Oslo.middleware: <=3.8.0, >=3.9.0 <=3.19.0, >=3.20.0 <=3.23.0 Description ~~~ Divya K Konoor with IBM reported a vulnerability in oslo.middleware. Software using the CatchError class may include sensitive values in the error message accompanying a Traceback, resulting in their disclosure. For example, complete API requests (including keystone tokens in their headers) may leak into neutron error logs. Patches ~~~ - https://review.openstack.org/425734 (Mitaka) - https://review.openstack.org/425732 (Newton) - https://review.openstack.org/425730 (Ocata) Credits ~~~ - Divya K Konoor from IBM (CVE-2017-2592) References ~~ - https://launchpad.net/bugs/1628031 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-2592 -- Jeremy Stanley signature.asc Description: Digital signature ___ 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] [openstack-dev] [OSSN-0074] Nova metadata service should not be used for sensitive information
On 2017-01-19 09:34:21 -0500 (-0500), Steve Gordon wrote: [...] > Does this configuration directive provide any mitigation for this > issue?: > > "use_forwarded_for = False (BoolOpt) Treat X-Forwarded-For > as the canonical remote address. Only enable this if you have a > sanitizing proxy." > > Just given its name and stated purpose it seems conspicuous by its > absence in this OSSN (that is, even if it provides no mitigation > at all I would have expected to see that noted)? [...] I agree it's unfortunate this was omitted in the discussion. If you follow the original bug report[*], it's only applicable to environments which set use_forwarded_for = True. The report can be reduced to the following summary: If you configure nova's metadata service to rely on X-Forwarded-For (by setting use_forwarded_for = True) so that you can put a proxy in front of it, then you need to make sure your network is correctly designed such that untrusted systems are not allowed to connect directly to the service without going through your proxy (and also make sure your proxy correctly rewrites any existing X-Forwarded-For headers it may receive rather than passing them through untouched). [*] https://launchpad.net/bugs/1563954 -- Jeremy Stanley signature.asc Description: Digital signature ___ 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] [openstack] How to modify company affiliation
On 2016-12-05 15:52:05 +0530 (+0530), Ravi Shekhar Jethani wrote: > I first signed OpenStack Foundation Member agreement > <https://www.openstack.org/join/register/?membership-type=foundation> some > time back as a part of some company but now I am working for a different > company. So to change affiliations: > > 1. Do I need to modify original agreement? > > 2. Do I need to submit a new agreement with current company as affiliation? > > For case 1, how and where I can do it because I cannot find a way to > see/edit my original agreement. I assume you're referring to the OpenStack Foundation Individual Member Agreement, which is purely an agreement between you and the OpenStack Foundation: https://www.openstack.org/legal/the-openstack-foundation-individual-member-agreement/ > To fulfill the affiliate status obligations in item #2 of that agreement, log in and edit your profile at https://www.openstack.org/profile/ amending or correcting the timeline for your affiliations as needed. > For case 2, I tried this but I get error: email already exists!!! I would > like to maintain same email. Correct, this fails because the system is attempting to prevent you signing up for duplicate accounts. Each member should have one and only one account in our foundation member system. Update the affiliations list in your current account's profile (as described above) rather than creating a new account. -- Jeremy Stanley signature.asc Description: Digital signature ___ 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
[Openstack] [OSSA 2016-012] Malicious qemu-img input may exhaust resources in Cinder, Glance, Nova (CVE-2015-5162)
OSSA-2016-012: Malicious qemu-img input may exhaust resources in Cinder, Glance, Nova :Date: October 06, 2016 :CVE: CVE-2015-5162 Affects ~~~ - Cinder: <=7.0.2, >=8.0.0 <=8.1.1 - Glance: <=11.0.1, ==12.0.0 - Nova: <=12.0.4, ==13.0.0 Description ~~~ Richard W.M. Jones of Red Hat reported a vulnerability that affects OpenStack Cinder, Glance and Nova. By providing a maliciously crafted disk image an attacker can consume considerable amounts of RAM and CPU time resulting in a denial of service via resource exhaustion. Any project which makes calls to qemu-img without appropriate ulimit restrictions in place is affected by this flaw. Patches ~~~ - https://review.openstack.org/382573 (cinder) (Liberty) - https://review.openstack.org/378012 (glance) (Liberty) - https://review.openstack.org/327624 (nova) (Liberty) - https://review.openstack.org/375625 (cinder) (Mitaka) - https://review.openstack.org/377736 (glance) (Mitaka) - https://review.openstack.org/326327 (nova) (Mitaka) - https://review.openstack.org/375102 (cinder) (Newton) - https://review.openstack.org/377734 (glance) (Newton) - https://review.openstack.org/307663 (nova) (Newton) - https://review.openstack.org/375099 (cinder) (Ocata) - https://review.openstack.org/375526 (glance) (Ocata) Credits ~~~ - Richard W.M. Jones from Red Hat (CVE-2015-5162) References ~~ - https://launchpad.net/bugs/1449062 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5162 Notes ~ - Separate Ocata patches are listed for Cinder and Glance, as they were fixed during the Newton release freeze after it branched from master. -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: Digital signature ___ 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
[Openstack] Wiki upgrade maintenance 21:00 UTC Friday, August 12
On Friday, August 12, from approximately 21:00 to 23:00 UTC our Mediawiki instance on wiki.openstack.org will be upgraded from its present 1.25 pre-release to the latest 1.27 version. We're allotting two hours in case issues are encountered with the upgrade requiring us to roll back to a snapshot, but if all goes well the outage will hopefully be much shorter. JP Maxwell, who has worked through the upgrade plan over recent weeks, set up a test instance for us at https://wiki-upgrade-test.openstack.org/ where interested parties can perform some preliminary tests over the next couple days and help us catch any important features/extensions which are broken or missing. Note this is running from a snapshot of the production database, so will not reflect content changed at wiki.openstack.org. Feel free to catch us in #openstack-infra or follow up to this message if you have any concerns or want additional information on this maintenance. -- Jeremy Stanley ___ 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] Send metrics to Graphite with StatsD
On 2016-06-16 19:15:59 +0200 (+0200), Matthias Runge wrote: > I think this message comes from a forum/email-list gateway, fed via > https://openstack.nimeyo.com/ > > Personally, I would think the format doesn't suit this list here well, > and just increases the noise, but doesn't provide any signal. > > :-/ I've just now used their feedback form to request that they stop forwarding messages to lists.openstack.org and cease giving users the impression they can participate in our mailing lists through that service. Also it looks like it might be using OpenStack trademarks/logo without authorization. -- Jeremy Stanley ___ 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] [oslo] Issues with pbr when building custom packages
On 2016-06-09 10:15:38 +1000 (+1000), Sam Morrison wrote:
> > On 9 Jun 2016, at 10:06 AM, Doug Hellmann wrote:
[...]
> > If you're doing your own packaging, how are you feeding the version
> > number into pbr? Via the environment variable?
>
> We’re building it based on the output of `git describe`
>
> We use
>
> GIT_DESCRIBE_VERSION_REGEX = re.compile(
> r"""
> ^v?(?P\d+)\.
> (?P\d+)
> (?:\.(?P\d+(\.\d+){0,1})){0,1}
> (?:-(?P\d+)
> -g(?P[0-9a-f]+)){0,1}$""",
> re.VERBOSE)
[...]
Note that you can just pass versions to PBR via the calling
environment, per
http://docs.openstack.org/developer/pbr/packagers.html#versioning
If yours is the NeCTAR packaging library I found (or is a fork
thereof), it looks like you're doing a lot of duplicative work for
things PBR can already handle like calculating patchsets since the
last tag and translating to suitable Debian package version numbers.
--
Jeremy Stanley
___
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] [oslo] Issues with pbr when building custom packages
On 2016-06-09 08:16:11 +1000 (+1000), Sam Morrison wrote: [...] > I'm packaging nova, we have a bunch of custom commits and extra > back ports in our version. Having the git hash in there is > extremely helpful and I also don't want to conflict with the > official openstack release. [...] I don't know whether it helps for your case, but the solution PBR implemented for that when it switched to PEP-440+semver (prior to that PBR _did_ include abbreviated Git SHAs in our version strings) was to store it in Python packaging metadata and add a separate command-line tool to list it. If the pbr library is installed into your environment, it includes an executable "pbr" entrypoint with a "freeze" subcommand with output similar to pip freeze except indicating the abbreviated Git SHAs included from the pbr.json file in each corresponding egg-info tree as an inline comment. -- Jeremy Stanley ___ 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] Usename change in gerrit
On 2016-05-31 09:49:19 + (+), dobroslaw.zyb...@ts.fujitsu.com wrote: > when I was setting username in gerrit I made small mistake (I ate on letter). > > Is it possible to fix that? Not really, no. Gerrit removed the ability to change usernames many years ago, and it currently assumes usernames are immutable (since it has features which depend on the username not changing once set). Modifying a username requires an administrator to directly edit a field in its SQL database backend. However, Gerrit only uses the username for API access, and for that you can mostly ignore the problem by configuring your ~/.ssh/config file with something like: Host openstack-gerrit HostName review.openstack.org User myGerritUsername Hope that helps! -- Jeremy Stanley ___ 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] there seems to be a conflict of IP port 6000 for swift
On 2016-04-29 08:41:46 -0600 (-0600), Mark Carlson wrote: > OpenStack could request a port number be assigned for default use: > https://tools.ietf.org/html/rfc6335 As discovered when Keystone did this several years ago, the port numbers being assigned at this stage have tipped over into the default ephemeral ports range for the Linux kernel, so chances are you'd run into the same nondeterministic deployment failures they did. -- Jeremy Stanley ___ 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] OpenStack Python SDK
On 2016-04-19 14:30:03 + (+), CHOW Anthony wrote: > List of OpenStack python clients can be found here: > > https://wiki.openstack.org/wiki/OpenStackClients [...] Also see http://developer.openstack.org/ for a broader SDK portal. -- Jeremy Stanley ___ 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] [COA] How to get involved
On 2015-12-09 09:21:51 -0800 (-0800), Adam Lawson wrote: > I know Foundation is working on the exams and certification > process for OpenStack Administrators. > > For someone who desires to participate/assist in this effort, who > is leading the charge? I can't seem to find reference to it > anywhere although I noticed a number of fellow sponsors were > listed in the press release as having participated thus far. I > didn't know the opportunity even existed so I am wondering is the > COA effort invite-only or did I just miss the email? I don't think there was any E-mail discussion on the general mailing list. It's unlikely to have come to your attention unless you've been closely following the board meetings. According to https://wiki.openstack.org/wiki/Governance/Foundation there is a board-appointed Professional Certification Working Group which holds periodic meetings (via conference call I think?) with a roster and minutes linked from https://wiki.openstack.org/wiki/Foundation/ProfessionalCertification (and I also see a contact E-mail address listed at the end of that page for people wishing to help). -- Jeremy Stanley ___ 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] What is the difference between cloudstack and openstack.
On 2015-10-24 12:44:04 +0530 (+0530), Venkatesh Kotipalli wrote: > Still now lot of confusion* What is the difference between cloudstack and > openstack ?* > any body know please please share important points. The most important difference to me: when CloudStack emerged into the open and was no longer simply the proprietary platform for VMOps/cloud.com, it was done under an "open core" model where some of it was still kept proprietary. This severely stunted the growth of any cohesive developer community around their platform. By comparison when NASA and Rackspace opened up the seeds of what is now OpenStack (a couple months later), it not only released the full working code bases for those projects but also went with an open development and design model and began work to transfer any original intellectual property assets to a forming nonprofit foundation. In the world of free software, community inertia is almost everything and far outweighs any relative differences in maturity of a code base, quality control, or feature set. This article from a few years ago when Citrix, who eventually acquired cloud.com, relicensed and donated CloudStack to the Apache Foundation, outlines what they recognized then as remaining deficiencies in openness (but in my opinion was an unfortunate matter of too little too late): http://buildacloud.org/blog/125-cloudstack-process-changes-working-the-apache-way.html > -- Jeremy Stanley ___ 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] [openstack][stackforge] incubation process
On 2015-09-22 15:04:14 +0800 (+0800), Gareth wrote: > Because of big tent, incubation process changes a little. I could see > some projects are moved from authors' private github repo, not > stackforge. My question is that is stackforge necessary anymore? It was never the intent that projects had to "incubate in StackForge" to join OpenStack officially, though it was always an option and so because it happened frequently many assumed it was required. Part of the reason for the "Big Tent" shift in governance was to get rid of incubation entirely and allow projects to become an official part of OpenStack with much less waiting and red tape. That aside, the Git namespace "stackforge" is currently a cosmetic implementation detail, not a semantic one, and its existence is creating more problems than it solves. As a result, we have stopped adding new projects with a "stackforge/" name prefix and only use "openstack/" for those now. We've scheduled[*] to either retire or rename all remaining repositories into the "openstack" namespace so that we can cease utilizing the "stackforge" prefix. This change does not convey any special meaning nor imply a difference in the governance of those projects, rather simply that the "openstack" namespace is no longer reserved strictly for official OpenStack projects. > Actually I hope yes, because I could make use of community's CI to > verify my draft codes. You can create unofficial projects in our infrastructure and then later apply to the Technical Committee for official status if and when you want. It's unusual to consider hosting an unofficial project in our infrastructure unless you eventually intend for it to join an existing official OpenStack project or form a new official OpenStack project. The TC may at some point decide to make this a more formal expectation, but for now there is no requirement to obtain any official status for your project. [*] http://lists.openstack.org/pipermail/openstack-dev/2015-August/073071.html -- Jeremy Stanley signature.asc Description: Digital signature ___ 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] OpenBSD ospf6d and ECMP
On 2015-08-25 15:59:42 + (+), Aviolat Romain wrote: > I'm having troubles with ospf6d and equal cost multipath, > > I have a very simple setup with three routers, 2x Arista L3 > switches and 1x OpenBSD box: > > Both switches are advertising the same subnets (for HA). > Apparently OpenBSD does not push two routes into the FIB but only > the first received. [...] Either you accidentally sent this to the wrong mailing list, or you're mistakenly assuming that OpenStack and OpenBSD are related in some way. They're not, and you haven't mentioned how (if at all) you're using OpenStack in your network. -- Jeremy Stanley ___ 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
[Openstack] [infra] ask.openstack.org offline for upgrade
Marton and I are taking the ask.openstack.org site offline for a couple hours to move it to a new server running a more recent OS, and upgrading the version of Askbot running on it so that support for Google authentication can be restored soon. The server should be offline no more than a couple hours, so expect to find it up and running again by 18:30 UTC. -- Jeremy Stanley ___ 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] [openstack-dev] [openstack-community] OpenStack Meiji (明治) - Our next release name has been selected
On 2015-07-08 10:08:07 -0400 (-0400), Monty Taylor wrote: > On 07/08/2015 01:51 AM, Tristan Goode wrote: [...] > > So let's give up naming things like toys in our play crib, start acting > > like grown ups and using semver or plain old integers. At worst, we might > > have some people see bugs in version 13. > > We already use semver. This is not a realistic solution to anything. To be slightly more specific... http://git.openstack.org/cgit/openstack/cinder/tag/?id=7.0.0.0b1 http://git.openstack.org/cgit/openstack/glance/tag/?id=11.0.0.0b1 http://git.openstack.org/cgit/openstack/neutron/tag/?id=7.0.0.0b1 http://git.openstack.org/cgit/openstack/ceilometer/tag/?id=5.0.0.0b1 http://git.openstack.org/cgit/openstack/heat/tag/?id=5.0.0.0b1 http://git.openstack.org/cgit/openstack/nova/tag/?id=12.0.0.0b1 http://git.openstack.org/cgit/openstack/trove/tag/?id=4.0.0.0b1 http://git.openstack.org/cgit/openstack/horizon/tag/?id=8.0.0.0b1 http://git.openstack.org/cgit/openstack/sahara/tag/?id=3.0.0.0b1 ...et cetera. Is the suggestion to take the mean of those release numbers to determine an "OpenStack" release identifier, or maybe a sum total? (This is of course a rhetorical question.) We're naming a release cycle which tracks the development process of a bunch of different releases of discrete components each with their own version numbers. Also, lets stop insulting people on public mailing lists by implying that they or their processes and customs are infantile. It's not constructive at all. Further, we should pick one mailing list on which to have this discussion rather than cross-posting to four. -- Jeremy Stanley ___ 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] Docs website https failure
On 2015-07-07 16:15:02 +0200 (+0200), Leslie-Alexandre DENIS wrote: > from my point of view and after some tests[1] from various locations, it > appears that docs.openstack.org refused connection on 443 at the moment. > > [1] curl: (7) Failed to connect to docs.openstack.org port 443: Connection > refused There is not, nor has there ever been, an https://docs.openstack.org site. What you want is http://docs.openstack.org instead. -- Jeremy Stanley ___ 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
[Openstack] [nova][stable][OSSA 2015-005] Nova console Cross-Site WebSocket hijacking (CVE-2015-0259)
On 2015-03-26 14:29:03 -0400 (-0400), Lars Kellogg-Stedman wrote: [...] > The solution, of course, is to make sure that the value of > novncproxy_base_url is set explicitly where the nova-novncproxy > service is running. This is a bit of a hack, since the service > *really* only cares about the protocol portion of the URL, > suggesting that maybe a new configuration option would have been a > less intrusive solution. [...] Thanks for the heads up. The developers working to backport security fixes to stable branches try to come up with ways to have them automatically applicable without configuration changes on the part of the deployers consuming them. Sometimes it's possible, sometimes it's not, and sometimes they think it is but turn out in retrospect to have introduced an unintended behavior change. Unfortunately I think that last possibility is what happened for this bug[1]. It's worth bringing this to the attention of the Nova developers who implemented the original fix to see if there's a better stable solution which achieves the goal of protecting deployments where operators aren't likely to update their configuration while still maintaining consistent behavior. To that end, I'm Cc'ing the openstack-dev list, setting MFT and tagging the subject accordingly. [1] https://launchpad.net/bugs/1409142 -- Jeremy Stanley ___ 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] [zuul][tempest] zuul tempest is broken
On 2014-12-23 11:27:49 +0800 (+0800), LIU Yulong wrote: > I noticed that all test tempest here are broken > http://status.openstack.org/zuul/. There is no passed tempest > check today. All patch with tempest check in review.openstack.org > will get a Jenkins -1 mark today. Please some zuul/tempest's > core/maintainer to check this issue. We've been working on it all day. Pip 6.0 was released today and it's taken most of the day to get DevStack working correctly with it. Should finally be resolved now, if you try rechecking. -- Jeremy Stanley ___ 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] error while installing pbr in devstack
On 2014-12-22 18:09:16 +0530 (+0530), Srinivasreddy R wrote:
> i am trying to install openstack branch stable/icehouse release through
> devstack on ubuntu 14.04 .
[...]
> ImportError: No module named pbr_json
> Complete output from command python setup.py egg_info:
> /usr/local/lib/python2.7/dist-packages/setuptools/dist.py:298:
> UserWarning: The version specified ('0.11.0.dev1.g1f5c9f7') is an invalid
> version, this may not work as expected with newer versions of setuptools, pip,
> and PyPI. Please see PEP 440 for more details.
[...]
It looks like you're using the master branch of PBR rather than a
release version. The current source in master is incompatible with
Setuptools 8 (released a week ago) and there is a patch series
currently under review to fix that. Either use the most recent
release of PBR instead (0.10.7 which should work with Setuptools 8)
or wait until https://review.openstack.org/142931 merges.
--
Jeremy Stanley
___
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
[Openstack] [OSSA 2014-035] Nova VMware driver may connect VNC to another tenant's console (CVE-2014-8750)
OpenStack Security Advisory: 2014-035 CVE: CVE-2014-8750 Date: October 14, 2014 Title: Nova VMware driver may connect VNC to another tenant's console Reporter: Marcio Roberto Starke Products: Nova Versions: up to 2014.1.3 Description: Marcio Roberto Starke reported a vulnerability in the Nova VMware driver. A race condition in its VNC port allocation may cause it to connect the wrong console if instances are created concurrently. By repeatedly spawning new instances, an authenticated user may be able to gain unauthorized console access to instances belonging to other tenants. Only Nova setups using the VMware driver and the VNC proxy service are affected. Juno (development branch) fix: https://review.openstack.org/114548 Icehouse fix: https://review.openstack.org/126425 Notes: This fix was included in the 2014.2rc1 release candidate and will appear in a future 2014.1.4 stable point release. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8750 https://launchpad.net/bugs/1357372 -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: Digital signature ___ 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] [openstack][neutron] tox -e py27 is not working in the latest neutron code
On 2014-09-12 10:14:00 + (+), Kelam, Koteswara Rao wrote: > I am trying to run unit test cases in neutron code using “tox –e > py27” but it is not working. [...] You already posted this development question to the openstack-dev list, which is the appropriate place for such discussions. Please do not post the same question to multiple mailing lists solely to broaden its audience. -- Jeremy Stanley ___ 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] OpenStack On Debian Jessie
On 2014-09-08 07:44:01 +0800 (+0800), Thomas Goirand wrote: [...] > However, what would be a terrible idea would be starting to use > Havana now. There's no work being done on Havana in Debian, and > there's no work that anyone will do. So you'd be pretty much on > your own, including for fixing any security issue. I believe > there's already some security fixes that you would miss. So by all > means, don't use Havana, and use Icehouse. [...] Also, OpenStack (upstream) has scheduled the final stable point release of Havana, 2013.2.4, for 10 days from now. After that, the OpenStack vulnerability management team will not be releasing security advisories specific to Havana nor preparing official backport patches for any bugs in Havana (security-related or otherwise). I would definitely discourage anyone from deploying Havana in new environments at this point... Icehouse has been available for months and Juno is just around the corner now. -- Jeremy Stanley ___ 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] [OpenStack-Infra] [Zuul] Understanding dequeue-on-new-patchset
On 2014-08-21 16:17:05 -0700 (-0700), James E. Blair wrote: > Jobs in the Gearman queue are definitely supposed to be canceled; if > not, that's a bug (and not a known one). It's not behavior I'd seen since some time last year, and while I remember it was fairly non-obvious when we spotted it I don't see any evidence it's happening now. So you're right it shouldn't be the case. I've at least dug up a change which got quickly cancelled by a new patchset before any jobs began, and confirmed they never ended up running on any Jenkins masters after removal from Gearman. -- Jeremy Stanley ___ 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] [OpenStack-Infra] [Zuul] Understanding dequeue-on-new-patchset
On 2014-08-21 15:11:13 -0700 (-0700), James E. Blair wrote: [...] > Strictly speaking, that will mean that every patchset will go through > the merger and Jenkins. But if testing for a patchset is in progress > when a new patchset is uploaded, the tests will abort. [...] One corner case I think we've seen which could lead to confusion is that once a job enters the Gearman queue it doesn't get removed even if Zuul removes it from the pipeline... so if your worker volume is backed up enough that some jobs for a patchset haven't been assigned before another patchset causes the current one to get dequeued, Jenkins can end up running those jobs anyway. Did we ever end up implementing a solution for that, or does that behavior still exist? -- Jeremy Stanley ___ 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] Issue with Security Groups
On 2014-06-27 11:30:48 + (+), Jeremy Stanley wrote:
> It's entirely likely you've discovered the behavior described in
> https://launchpad.net/bugs/1043886 (if so, then yes, a known issue).
Actually, I meant to say https://launchpad.net/bugs/1316822 but the
first one is what came up when I was searching, and they both look
suspiciously similar.
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
___
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] Issue with Security Groups
On 2014-06-27 19:12:31 +0800 (+0800), sylecn wrote: > On Thu, Jun 26, 2014 at 9:37 AM, Muralidhar Balcha > wrote: > [...] > > Is this a known issue? Does it have something to with the default > > security group. How can I make security group settings persist across > > service restarts? > > Not as far as I know. Security groups are meant to be persistent by > design. You don't need to do anything. It's entirely likely you've discovered the behavior described in https://launchpad.net/bugs/1043886 (if so, then yes, a known issue). -- Jeremy Stanley ___ 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] Is there a sample application source code run on openStack?
On 2014-06-09 16:43:25 +0430 (+0430), hossein zabolzadeh wrote: [...] > "In order to fully leverage the openstack infrastructure services, > your application source code need to be changed". [...] Rephrased into a cliché car analogy (because everyone loves those, right?), "In order to fully leverage a race track, you need a race car." However, that doesn't mean your unmodified family sedan will be slower on a race track than on the highway. -- Jeremy Stanley ___ 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] Is there a sample application source code run on openStack?
On 2014-06-09 16:43:25 +0430 (+0430), hossein zabolzadeh wrote: [...] > I want to check how the application code (e.g. MediaWiki source > code), need to be changed to work on the openstack. Strictly > speaking, I hear a lot about this: "In order to fully leverage the > openstack infrastructure services, your application source code > need to be changed". I want to know which parts of my > application(e.g. My customized Joomla) needs to be change... I'm not sure where you're hearing this from, but you seem to have some misconceptions. For example, the OpenStack Infrastructure Team manages numerous unmodified "stateful" applications on donated resources from OpenStack-based service providers for the benefit of our contributors and the broader community (Gerrit, Jenkins, even Mediawiki!). You start a virtual machine with whatever operating system you need and install and run your software on it for as long as you need (including indefinitely). Just make sure to pick a service provider with some guarantees about uptime and not deleting your systems, maybe one who also offers load balancing/fail-over solutions too (same concerns as in a non-"cloud" deployment). Yes, to take advantage of modern concepts like automatic elastic scaling you may need applications which support those sorts of deployment methods, but under the hood OpenStack provides virtual machines--so if your needs can be met on VMs then they're probably just fine to manage through OpenStack. -- Jeremy Stanley ___ 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
[Openstack] [OSSA 2014-017] Nova VMWare driver leaks rescued images (CVE-2014-2573)
OpenStack Security Advisory: 2014-017 CVE: CVE-2014-2573 Date: May 29, 2014 Title: Nova VMWare driver leaks rescued images Reporter: Jaroslav Henner (Red Hat) Products: Nova Versions: from 2013.2 to 2013.2.3, and 2014.1 Description: Jaroslav Henner from Red Hat reported a vulnerability in Nova. By requesting Nova place an image into rescue, then deleting the image, an authenticated user my exceed their quota. This can result in a denial of service via excessive resource consumption. Only setups using the Nova VMWare driver are affected. Juno (development branch) fix: https://review.openstack.org/75788 https://review.openstack.org/80284 Icehouse fix: https://review.openstack.org/88514 https://review.openstack.org/89217 Havana fix: https://review.openstack.org/89762 https://review.openstack.org/89768 Notes: This fix will be included in the juno-1 development milestone and in future 2013.2.4 and 2014.1.1 releases. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2573 https://launchpad.net/bugs/1269418 -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: Digital signature ___ 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] Question about my company info in stackalytics
On 2014-04-18 08:20:59 +0530 (+0530), Rajdeep Dua wrote: > How do i get that CL reviewed? Try reaching out to the core reviewers for that project if it's not getting attention: https://review.openstack.org/#/admin/groups/183,members -- Jeremy Stanley ___ 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] Question about my company info in stackalytics
On 2014-04-16 06:08:08 -0700 (-0700), dua_rajd...@yahoo.com wrote: > how do you update the json? using gerrit or there is some other > process. Yes, through the Gerrit instance at review.openstack.org. You probably want to propose an update to https://git.openstack.org/cgit/stackforge/stackalytics/tree/etc/default_data.json or one of the other files in the same directory. -- Jeremy Stanley ___ 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] Pip Error In Swift Installation (Swift All in One tutorial for a single node)
On 2014-03-26 08:17:14 +0100 (+0100), Christian Schwede wrote: > looks like your pip version is to old [...] Yes, it's worth pointing out that pip versions prior to 1.4 did not validate (or in some cases even attempt to use) HTTPS during package download, making it significantly less secure. It also had undesirable behaviors like installing pre-release versions by default and spidering external Web sites to find packages not hosted directly on PyPI. However, the error being encountered there should be solved when https://launchpad.net/bugs/1296310 is fixed and a new version of pbr released with the corresponding patch included. -- Jeremy Stanley ___ 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
[Openstack] [OSSA 2014-004] Glance Swift store backend password leak (CVE-2014-1948)
OpenStack Security Advisory: 2014-004 CVE: CVE-2014-1948 Date: February 12, 2014 Title: Glance Swift store backend password leak Reporter: Nikhil Komawar (Rackspace) Products: Glance Versions: 2013.2 versions up to 2013.2.1 Description: Nikhil Komawar from Rackspace reported an information leak in Glance logs. The password for the Swift store backend is logged at WARNING level as part of the URL when authentication to a store fails if image location is not disabled by policy or the store is a single-tenant configuration. An attacker with access to the logs (local shell, log aggregation system access, or accidental leak) may leverage this vulnerability to elevate privileges and gain direct full access to the Glance Swift store backend. Only Glance setups using the Swift store backend are affected. Icehouse (development branch) fix: https://review.openstack.org/71419 Havana fix: https://review.openstack.org/72473 Notes: This fix will be included in the icehouse-2 development milestone and the upcoming 2013.2.2 release. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1948 https://launchpad.net/bugs/1275062 -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: Digital signature ___ 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] Security Breach! Tenant A is seeing the VNC Consoles of Tenant B!
On 2013-12-22 15:37:02 -0200 (-0200), Martinx - ジェームズ wrote: [...] > This is a very serious problem, since I'm giving to the "Tenant > A", almost total access to "Tenant B" Instances!! This kind of > situation should NEVER occur! > > What can I do to completely block this? [...] Is it possible the user for Tenant A is an admin account? Remember, admins are global administrators regardless of what tenant they might be associated with. -- Jeremy Stanley ___ 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] Additional Grizzly releases?
On 2013-12-17 10:15:28 -0700 (-0700), David Medberry wrote: > This page, presumably correct, shows one more Grizzly release in > March: > https://wiki.openstack.org/wiki/StableBranchRelease > > Planned stable/grizzly releases > > 2013.1.5 Mar 20 2014 It's worth noting that we're still merging changes to integrated projects' stable/grizzly branches if you're looking for particular fixes, for example... http://git.openstack.org/cgit/openstack/nova/log/?h=stable/grizzly ...and if there's anything fixed in Havana or Icehouse which you want to see backported to Grizzly while it's still supported, make sure to comment on relevant bugs, tag them with grizzly-backport-potential and if possible submit fixes for review... https://bugs.launchpad.net/nova/+bugs?field.tag=grizzly-backport-potential Support of stable releases is determined mostly by the level of activity in the community working to provide that support, after all. -- Jeremy Stanley ___ 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
[Openstack] [OSSA 2013-036] Insufficient sanitization of Instance Name in Horizon (CVE-2013-6858)
OpenStack Security Advisory: 2013-036 CVE: CVE-2013-6858 Date: December 11, 2013 Title: Insufficient sanitization of Instance Name in Horizon Reporter: Cisco PSIRT Products: Horizon Affects: All supported releases Description: Cisco PSIRT reported a vulnerability in the OpenStack Horizon dashboard. By embedding HTML tags in an Instance Name, a tenant may execute a script within an administrator's browser resulting in a cross-site scripting (XSS) attack. Only setups using the Horizon dashboard are affected. Icehouse (development branch) fix: https://review.openstack.org/55175 Havana fix: https://review.openstack.org/58465 Grizzly fix: https://review.openstack.org/58820 Notes: This fix is included in the icehouse-1 development milestone and will appear in a future 2013.2.1 stable point release. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6858 https://launchpad.net/bugs/1247675 -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: Digital signature ___ 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
[Openstack] [OSSA 2013-032] Keystone trust circumvention through EC2-style tokens (CVE-2013-6391)
OpenStack Security Advisory: 2013-032 CVE: CVE-2013-6391 Date: December 11, 2013 Title: Keystone trust circumvention through EC2-style tokens Reporter: Steven Hardy (Red Hat) Products: Keystone Affects: Havana and later Description: Steven Hardy from Red Hat reported a vulnerability in Keystone trusts when used in conjunction with the ec2tokens API. By generating EC2 credentials using a trust-scoped token, a trustee may retrieve a token not scoped to the trust, therefore elevating privileges to all of the trustor's roles. Only Keystone setups enabling EC2-style authentication are affected. Icehouse (development branch) fix: https://review.openstack.org/61419 Havana fix: https://review.openstack.org/61425 Notes: This fix will be included in the icehouse-2 development milestone and in a future 2013.2.1 release. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6391 https://launchpad.net/bugs/1242597 -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: Digital signature ___ 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
[Openstack] [OSSA 2013-033] Metadata queries from Neutron to Nova are not restricted by tenant (CVE-2013-6419)
OpenStack Security Advisory: 2013-033 CVE: CVE-2013-6419 Date: December 11, 2013 Title: Metadata queries from Neutron to Nova are not restricted by tenant Reporter: Aaron Rosen (VMware) Products: Neutron, Nova Affects: All supported releases Description: Aaron Rosen from VMware reported a vulnerability in the metadata access from OpenStack Neutron to Nova. Because of a missing authorization check on port binding, by guessing an instance_id a tenant may retrieve another tenant's metadata resulting in information disclosure. Only OpenStack setups running neutron-metadata-agent are affected. Icehouse (development branch) fix: https://review.openstack.org/61439 (neutron) https://review.openstack.org/61428 (nova) Havana fix: https://review.openstack.org/61442 (neutron) https://review.openstack.org/61435 (nova) Grizzly fix: https://review.openstack.org/61443 (neutron) https://review.openstack.org/61437 (nova) Notes: This fix will be included in the icehouse-2 development milestone and in a future 2013.2.1 release. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6419 https://launchpad.net/bugs/1235450 -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: Digital signature ___ 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
[Openstack] [OSSA 2013-035] Heat ReST API doesn't respect tenant scoping (CVE-2013-6428)
OpenStack Security Advisory: 2013-035 CVE: CVE-2013-6428 Date: December 11, 2013 Title: Heat ReST API doesn't respect tenant scoping Reporter: Steven Hardy (Red Hat) Products: Heat Affects: All supported releases Description: Steven Hardy from Red Hat reported a vulnerability in the Heat ReST API. By changing the request path, an authenticated client may override their tenant scope resulting in privilege escalation. Only setups exposing the Heat orchestration ReST interface are affected. Icehouse (development branch) fix: https://review.openstack.org/61455 Havana fix: https://review.openstack.org/61456 Notes: This fix will be included in the icehouse-2 development milestone and in a future 2013.2.1 release. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6428 https://launchpad.net/bugs/1256983 -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: Digital signature ___ 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
[Openstack] [OSSA 2013-034] Heat CFN policy rules not all enforced (CVE-2013-6426)
OpenStack Security Advisory: 2013-034 CVE: CVE-2013-6426 Date: December 11, 2013 Title: Heat CFN policy rules not all enforced Reporter: Steven Hardy (Red Hat) Products: Heat Affects: All supported releases Description: Steven Hardy from Red Hat reported a vulnerability in Heat's default API policy enforcement. By calling the CreateStack or UpdateStack methods, an in-instance user may be able to create or update a stack in violation of the default policy. Only setups using Heat's cloudformation-compatible API are affected. Icehouse (development branch) fix: https://review.openstack.org/61452 Havana fix: https://review.openstack.org/61454 Notes: This fix will be included in the icehouse-2 development milestone and in a future 2013.2.1 release. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6426 https://launchpad.net/bugs/1256049 -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: Digital signature ___ 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
[Openstack] [OSSA 2013-034] Heat CFN policy rules not all enforced (CVE-2013-6426)
OpenStack Security Advisory: 2013-034 CVE: CVE-2013-6426 Date: December 11, 2013 Title: Heat CFN policy rules not all enforced Reporter: Steven Hardy (Red Hat) Products: Heat Affects: All supported releases Description: Steven Hardy from Red Hat reported a vulnerability in Heat's default API policy enforcement. By calling the CreateStack or UpdateStack methods, an in-instance user may be able to create or update a stack in violation of the default policy. Only setups using Heat's cloudformation-compatible API are affected. Icehouse (development branch) fix: https://review.openstack.org/61452 Havana fix: https://review.openstack.org/61454 Notes: This fix will be included in the icehouse-2 development milestone and in a future 2013.2.1 release. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6426 https://launchpad.net/bugs/1256049 -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: Digital signature ___ 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] vmwareapi with VMwareESXDriver
On 2013-12-04 09:03:46 +0800 (+0800), Hai Quan Chen wrote: > ESXi 5.x could virtualize on Mac hardware. > > In my lab, I have a running ESXi on Mac mini server, which > connects to Openstack via vCenter. Good point. What I meant was legally possible, but only if buying the servers for your compute nodes from Apple. Otherwise they won't license the OS to you, virtual or not. -- Jeremy Stanley ___ 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] vmwareapi with VMwareESXDriver
On 2013-12-03 14:47:48 -0800 (-0800), Stefano Maffulli wrote: [...] > If so, I haven't heard of anybody virtualizing OS X but I'd be happy to > be proven wrong. As recently as last year a former employer of mine was looking into it, but the issue turned out to be one of licensing. Apple didn't license OS X for running on any hardware except their own, so while there were some ways to make it technically possible it was not _legally_ possible. This also seems to be reflected in VMware's knowledge base now... http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1000131 > -- Jeremy Stanley ___ 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] [Nova] Proposed removal of the PowerVM driver
On 2013-11-22 16:55:04 -0500 (-0500), Russell Bryant wrote: > I'm not sure I see much value in removing it from past releases. > There isn't much cost to leaving them there I think. [...] For example, would you entertain stable bug fixes and security fixes/advisories specific to this driver? Or is there some middle ground to keeping the code intact in Grizzly/Havana but not really supporting it? -- Jeremy Stanley ___ 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
[Openstack] [OSSA 2013-030] XenAPI security groups not kept through migrate or resize (CVE-2013-4497)
OpenStack Security Advisory: 2013-030 CVE: CVE-2013-4497 Date: November 14, 2013 Title: XenAPI security groups not kept through migrate or resize Reporter: Chris Behrens (Rackspace) and Vangelis Tasoulas Products: Nova Affects: All supported versions prior to Havana Description: Chris Behrens with Rackspace and Vangelis Tasoulas reported a set of vulnerabilities in OpenStack Nova's XenAPI hypervisor backend. When migrating or resizing an instance, including live migration, existing security groups may not be reapplied after the operation completes. This can lead to unintentional network exposure for virtual machines. Only setups using the XenAPI backend are affected. The Havana release (2013.2) is not affected. Grizzly fixes (will be included in a future stable point release): https://review.openstack.org/52987 https://review.openstack.org/52991 References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4497 https://launchpad.net/bugs/1073306 https://launchpad.net/bugs/1202266 -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: Digital signature ___ 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] Promoting the role of +1 reviewers in our community
On 2013-10-30 10:08:03 +1100 (+1100), Tom Fifield wrote: [...] > Do you see this too? Very often, in fact--I was just marveling at it again this morning. Thanks for breaching the subject! > How can we help encourage more +1 reviews? I've been toying with the idea of asking change submitters to seek additional +1 reviews when they come asking for a core reviewer to have a look at a patch (which seems like half of the traffic in the development-focused IRC channels I live on). You might also solicit suggestions on the topic from the openstack-dev mailing list rather than this one. Just a thought. > Anyway, here's cheers to all the non-core reviewers :) Hear hear! -- Jeremy Stanley ___ 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] Openstack IN a Virtual Machine?
On 2013-10-02 10:34:55 +0100 (+0100), James Page wrote: [...] > we actually do OpenStack testing on OpenStack to support QA > activities for Ubuntu Server. [...] And in fact, every change which gets proposed to OpenStack is tested many, many, many times before it's allowed in OpenStack by running OpenStack (DevStack) on OpenStack (donated virtual machines from OpenStack Foundation member companies who happen to be public cloud service providers). We quite probably install more individual instances of OpenStack than anyone else, building and destroying hundreds of them every hour at the moment, and do it all on virtual machines managed by other OpenStacks. -- Jeremy Stanley ___ 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
[Openstack] [OSSA 2013-021] Cinder LVM volume driver does not support secure deletion (CVE-2013-4183)
OpenStack Security Advisory: 2013-021 CVE: CVE-2013-4183 Date: August 7, 2013 Title: Cinder LVM volume driver does not support secure deletion Reporter: Rongze Zhu (UnitedStack) Products: Cinder Affects: 2013.1 (Grizzly) and later Description: Rongze Zhu from UnitedStack reported a vulnerability in the Cinder LVM volume driver. The contents of LVM snapshots may not be cleared upon deletion even when secure deletes are configured, resulting in potential exposure of latent data to subsequent servers for other tenants. Only setups using LVMVolumeDriver are affected. Havana (development branch) fix: https://review.openstack.org/36506 Grizzly fix: https://review.openstack.org/39565 Notes: This fix is included in the havana-2 development milestone and will appear in a future 2013.1.3 release. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4183 https://launchpad.net/bugs/1198185 -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: Digital signature ___ 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
[Openstack] [OSSA 2013-019] Resource limit circumvention in Nova private flavors (CVE-2013-2256)
OpenStack Security Advisory: 2013-019 CVE: CVE-2013-2256 Date: August 6, 2013 Title: Resource limit circumvention in Nova private flavors Reporter: hzrandd (NetEase) Products: Nova Affects: All versions Description: hzrandd from NetEase reported a resource limit circumvention vulnerability in Nova's handling of private flavors. Any tenant is able to show and boot any other tenant's private flavors by guessing a flavor ID. This not only exposes the flavor's name, memory and disk size, swap allocation, VCPU count and similar flavor properties, but potentially allows circumvention of any resource limits enforced through the os-flavor-access:is_public property. Havana (development branch) fix: https://review.openstack.org/34963 Grizzly fix: https://review.openstack.org/37992 Folsom fix: https://review.openstack.org/38318 Notes: This fix is included in the havana-2 development milestone and will appear in a future 2013.1.3 release. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2256 https://bugs.launchpad.net/nova/+bug/1194093 -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: Digital signature ___ 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
[Openstack] [OSSA 2013-020] Denial of Service in Nova network source security groups (CVE-2013-4185)
OpenStack Security Advisory: 2013-020 CVE: CVE-2013-4185 Date: August 6, 2013 Title: Denial of Service in Nova network source security groups Reporter: Vishvananda Ishaya (Nebula) Products: Nova Affects: All versions Description: Vishvananda Ishaya from Nebula reported a denial of service vulnerability in Nova's handling of network source security group policy updates. By performing a large number of server creation operations, the proportion of updates increases quadratically and may overwhelm nova-network such that it is no longer able to service other requests in a timely fashion. Only setups relying on nova-network are affected. Havana (development branch) fix: https://review.openstack.org/39541 Grizzly fix: https://review.openstack.org/39543 Folsom fix: https://review.openstack.org/39544 Notes: This fix will be included in the havana-3 development milestone and in a future 2013.1.3 release. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4185 https://bugs.launchpad.net/nova/+bug/1184041 -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: Digital signature ___ 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] DevStack doesn't support Debian Wheezy?
On 2013-08-01 13:36:54 +0300 (+0300), Roman Gorodeckij wrote: [...] > I've asked a question on launchpad [...] For the most part, the OpenStack community is no longer active on Launchpad Questions. You might have better luck re-posting to http://ask.openstack.org/ or E-mailing the Debian-OpenStack Team's Alioth list, . -- Jeremy Stanley ___ 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] Long lag in mailing list
On 2013-07-31 11:51:42 +0900 (+0900), Jake G. wrote: > I have noticed it sometimes takes an hour or more for some of my > messages to get sent out from the new mailing list address. Anyone > else notice this? The list server wasn't sufficiently tuned for the substantial subscriber base of the migrated list. Queue settings are being tweaked to chew through the delivery backlog and get things back on track, so hopefully should be much quicker soon. -- Jeremy Stanley ___ 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
