Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE
On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer mba...@redhat.com wrote: can you elaborate on your reasoning that FK constraints should be used less overall? or do you just mean that the client side should be mirroring the same rules that would be enforced by the FKs? I don't think he means that we will use them less. Our SQL backends are full of them. What Keystone can't do is rely on them because not all implementations of our backends support FKs. -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek www: http://dstanek.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE
On March 8, 2015 at 11:24:37 AM, David Stanek (dsta...@dstanek.com) wrote: On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer mba...@redhat.com wrote: can you elaborate on your reasoning that FK constraints should be used less overall? or do you just mean that the client side should be mirroring the same rules that would be enforced by the FKs? I don't think he means that we will use them less. Our SQL backends are full of them. What Keystone can't do is rely on them because not all implementations of our backends support FKs. 100% spot on David. We support implementations that have no real concept of FK and we cannot assume that a cascade (or restrict) will occur on these implementations. —Morga -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek www: http://dstanek.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Glance] Glance K-3 reviews.
Hi all, This is a gentle reminder on the ML regarding Kilo-3 related reviews. Similar announcements have been made in the past few weeks during the Glance meetings [2]. A small summary of what the current status looks like for k-3 Glance: 1. Feature freeze for Glance is Mar 12th. 2. [1] has the list of specs/BPs targeted for Kilo. (They are also our priorities for this cycle). 3. [1] should also give information regarding what needs to be reviewed. Many of the specs have a mature enough code; and a little chance for them to need major feedback. So, they are basically waiting on core reviewers to show up. 4. Please prefer to review specs over bugs at the moment as we can target bugs after Mar 12th before official freeze on Mar 19th (and some others during the RCs). 5. Only Artifacts, Catalog Index Service and Deactivate an Image specs have been proposed for possible FFE candidates (based on the momentum they have been having in discussions and commitment of members to get issues resolved). 6. We are planning to do a release of the client and store lib before the official freeze for accommodating some of the features. 7. If you need more details, please refer to [2] and look for logs of meetings on or after Feb 12th for K3 related updates. If you still have questions, then feel free to reach out. Please remember this is a busy period so, turn around time will be more. P.S. As some of the reviewers (and core-reviewers like Flavio and Zhi Yan) are not able to make it to the meetings often, this is a special announcement being made for their convenience. [1] https://launchpad.net/glance/+milestone/kilo-3 [2] http://eavesdrop.openstack.org/meetings/glance/2015/ Thanks, -Nikhil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Question about bug 1314614
On 6 March 2015 at 13:16, Sławek Kapłoński sla...@kaplonski.pl wrote: Hello, Today I found bug https://bugs.launchpad.net/neutron/+bug/1314614 because I have such problem on my infra. (For reference, if you delete a port that a Nova is using - it just goes ahead and deletes the port from Neutron and leaves the VIF in an odd state, disconnected and referring to a port that no longer exists.) I saw that bug is In progress but change is abandoned quite long time ago. I was wondering is it possible that neutron will send notification to nova that such port was deleted in neutron? I know that in Juno neutron is sending notifications to nova when port is UP on compute node so maybe same mechanism can be used to notify nova that port is no longer exists and nova should delete it? What behaviour are you looking for? The patch associated with the bug falls attempts to stop deletion of used ports. It falls far short of implementing consistent behaviour, which would have to take into account everything that used ports (including DHCP, L3, network services, etc.), it would probably need to add an 'in-use' flag to the port itself, and it changes the current API behaviour rather markedly. We could go there but there's much more code to be written. Someone on the bug suggests removing the VIF from the instance if the port is deleted, but I don't think that's terribly practical - for some instance containers it would not be possible. The current behaviour does seem to be consistent and logical, if perhaps unexpected and a bit rough around the edges. I'm not sure orphaning and isolating a VIF is actually a bad thing if you know it's going to happen, though it needs to be clear from the non-Neutron side that the VIF is no longer bound to a port, which is where things seem to fall down right now. I've also found no documentation about when delete should work and when it shouldn't, or what happens if the port is bound (the API and CLI document say that the operation 'deletes a port' and not much else). -- Ian. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.
Oh, it means 3:00AM for me :-( On 09/03/15 09:07, Nikhil Komawar wrote: Hi all, Currently, we've alternating time for Glance meetings. Now, with the Daylight savings being implemented in some parts of the world, we're thinking of moving the meeting time to just one slot i.e. earlier in the day(night). This solves the original conflicting times issue that a subset of the individuals had; to add to that the schedule is less confusing and unified. So, the new proposal is: Glance meetings [1] to be conducted weekly on Thursdays at 1400UTC [2] on #openstack-meeting-4 This would be implemented on Mar 19th, given there are no major objections. Please vote with +1/-1 here. [1] https://wiki.openstack.org/wiki/Meetings#Glance_Team_meeting [2] http://www.timeanddate.com/worldclock/fixedtime.html?hour=14min=0sec=0 Thanks, -Nikhil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Cheers Best regards, Fei Long Wang (王飞龙) -- Senior Cloud Software Engineer Tel: +64-48032246 Email: flw...@catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington -- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Glance] Proposal to change Glance meeting time.
Hi all, Currently, we've alternating time for Glance meetings. Now, with the Daylight savings being implemented in some parts of the world, we're thinking of moving the meeting time to just one slot i.e. earlier in the day(night). This solves the original conflicting times issue that a subset of the individuals had; to add to that the schedule is less confusing and unified. So, the new proposal is: Glance meetings [1] to be conducted weekly on Thursdays at 1400UTC [2] on #openstack-meeting-4 This would be implemented on Mar 19th, given there are no major objections. Please vote with +1/-1 here. [1] https://wiki.openstack.org/wiki/Meetings#Glance_Team_meeting [2] http://www.timeanddate.com/worldclock/fixedtime.html?hour=14min=0sec=0 Thanks, -Nikhil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.
On Sun, Mar 08, 2015 at 08:07:33PM +, Nikhil Komawar wrote: So, the new proposal is: Glance meetings [1] to be conducted weekly on Thursdays at 1400UTC [2] on #openstack-meeting-4 +1 It was nice to try out the alternating meeting times. However, I don't think it brought many benefits, and made scheduling harder. Louis signature.asc Description: Digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE
Morgan Fainberg morgan.fainb...@gmail.com wrote: In general I'd say that cascade is the right approach. There are some very limited cases where restrict should be used. Overall, I'd like to see less reliance on FK constraints anywhere. can you elaborate on your reasoning that FK constraints should be used less overall? or do you just mean that the client side should be mirroring the same rules that would be enforced by the FKs? The reason for using Cascade is that we should be very specific in our code to prevent deletion independent of the backend (move these checks to the controller level) if we want to prevent deletion cascades. In short, we should not rely on an implementation specific detail to know if we can / cannot delete something. --Morgan On Sat, Mar 7, 2015 at 7:37 PM, Chen, Wei D wei.d.c...@intel.com wrote: Hi, I did some homework to follow up the inline comment about on delete cascade subclauses of the foreign key clause[1], when ' ON DELETE CASCADE ' is given, delete a recode from parent table will DELETE all the corresponding rows from the CHILD table automatically *without any warning*. 'ON DELETE RESTRICT' looks different, it will fail complaining about the existing child rows, this is the default foreign key relationship behavior, this seems give end user a chance to double check the data. I did a quick test against the table 'endpoint_group', the output error message like below, mysql delete from endpoint_group; ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`keystone`.`project_endpoint_group`, CONSTRAINT `project_endpoint_group_ibfk_1` FOREIGN KEY (`endpoint_group_id`) REFERENCES `endpoint_group` (`id`)) I am a little confused about two different subclauses as both of them can be found in the table definition of SQL backends, it hard to say which one is better, is it worthwhile to move all of them to ON DELETE CASCADE or ON DELETE RESTRICT? [1] https://review.openstack.org/#/c/151931/5/keystone/contrib/endpoint_filter/migrate_repo/versions/002_add_endpoint_groups.py Best Regards, Dave Chen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Do No Evil
Ian Wells ijw.ubu...@cack.org.uk wrote: With apologies for derailing the question, but would you care to tell us what evil you're planning on doing? I find it's always best to be informed about these things. All of us, every day, do lots of things that someone is going to think is evil. From eating meat, to living various kinds of lifestyles, to supporting liberal or conservative causes, to just living in a certain country, to using Windows or other “non-free” operating systems, to top-posting, makes you evil to someone; to lots of people, in fact. This is why a blanket statement like “do no evil” is pretty much down to two choices, A. based on some arbitrary, undefined notion of “evil” in which case nobody can use the software, or B. based on the user’s own subjective view of “evil” which means the phrase is just a humorous frill. Maybe authors add this phrase as a means to limit the use of their software only to those communities where such a statement is patently ridiculous (e.g., not publicly held corporations). but also given that “evil” can be almost anything, I don’t think it’s reasonable that users would have to report on their intended brand of “evil”. -- Ian. (Why yes, it *is* a Saturday morning.) On 6 March 2015 at 12:23, Michael Krotscheck krotsch...@gmail.com wrote: Heya! So, a while ago Horizon pulled in JSHint to do javascript linting, which is awesome, but has a rather obnoxious Do no evil licence in the codebase: https://github.com/jshint/jshint/blob/master/src/jshint.js StoryBoard had the same issue, and I've recently replaced JSHint with ESlint for just that reason, but I'm not certain it matters as far as OpenStack license compatibility. I'm personally of the opinion that tools used != code shipped, but I am neither a lawyer nor a liable party should my opinion be wrong. Is this something worth revisiting? Michael __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Core nominations.
Thank you for the feedback Flavio and Gary! I've noted down your concerns and will address them in a separate thread. So, I think we'd go ahead with nominations mentioned here (by Monday) and start the core-member discussion later. Thanks, -Nikhil From: Gary Kotton gkot...@vmware.com Sent: Sunday, March 8, 2015 11:45 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. On 3/8/15, 2:34 PM, Flavio Percoco fla...@redhat.com wrote: On 07/03/15 23:16 +, Nikhil Komawar wrote: Thank you for the response, Hemanth! Those are some excellent questions. In order to avoid diverging the conversation, I would like to give my general sense of direction. Please do keep in mind that a lot of these thoughts need to be better formulated, preferably on a different thread. Core-members would be generic concept unlike core-reviewers. The one important thing that this should achieve is clear understanding of the individuals (usually ones who are new or interact less often in Glance) - who actually is a Core in the program? There are a few things that can be part of their rights like being able to vote for important decisions (like the current thread), they may or may not have core-reviewer rights based on their participation area. For example, they could be security liaison or they may _officially_ do release management for the libraries without being a core-reviewer, etc. The responsibilities should complement the rights. Those are just initial thoughts and can be better formulated. I will attempt to craft out the details of the core-member concept in the near future and you all are welcome to join me in doing so. I think I misread the original proposal with ragards to core-members. As it is explained here, I'm opposed on having this. As soon as you start tagging people and adding more layers to the community, it'll be harder to manage it and more importantly it'll be more fragmented than it is, which is something I believe we don't need. Agree 100% Citing the example you mentioned in your previous email: There are a few things that can be part of their rights like being able to vote for important decisions This breaks openess and it reads like: If you're not a 'core-member', your vote won't count We've fought hard to remove all these kind of labels and exclusive rights by reducing them to the minimum, hence the core-reviewers team. Anyone should feel free to vote, speak up and most importantly, everyones opinion *must* be taken into account. I'll wait for your final proposal to give a more constructive and extended opinion based on that. Flavio Hope that answered your questions, at least for the time being! Cheers -Nikhil ━ ━━ From: Hemanth Makkapati hemanth.makkap...@rackspace.com Sent: Friday, March 6, 2015 7:15 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. I like the idea of a 'core-member'. But, how are core-members different from core-reviewers? For instance, with core-reviewers it is very clear that these are folks you would trust with merging code because they are supposed to have a good understanding of the overall project. What about core-members? Are core-members essentially just core-reviewers who somehow don't fit the criteria of core-reviewers but are good candidates nevertheless? Just trying to understand here ... no offense meant. Also, +1 to both the criteria for removing existing cores and addition of new cores. -Hemanth. ━ ━━ From: Nikhil Komawar nikhil.koma...@rackspace.com Sent: Friday, March 6, 2015 4:04 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. Thank you all for the input outside of the program: Kyle, Ihar, Thierry, Daniel! Mike, Ian: It's a good idea to have the policy however, we need to craft one that is custom to the Glance program. It will be a bit different to ones out there as we've contributors who are dedicated to only subset of the code - for example just glance_store or python-glanceclient or metadefs. From here on, we may see that for Artifacts and other such features. It's already being observed for metadefs. While I like Mike's suggestion to (semi-)adopt what Nova and Neutron are doing, it also makes me wonder if that's going to help us in long term. If not, then what can we do now to set a good path forward? Flavio, Erno, Malini, Louis, Mike: Drafting a guideline policy and implementing rotation based on that was my intent so that everyone is aware of the changes in the program. That would let the core reviewers know what their duties are and let non-cores know what they need to do to become cores. Moreover, I've a idea for
[openstack-dev] About Sahara EDP New Ideas for Liberty
Hi all. We got several feedbacks about Sahara EDP's future from some China customers. Here are some ideas we would like to share with you and need your input if we can implement them in Sahara(Liberty). 1. Add a schedule feature to run the jobs on time: This request comes from the customer, they usually run the job in a specific time every day. So it should be great if there is a scheduler to help arrange the regular job to run. 2. A more complex workflow design in Sahara EDP: Current EDP only provide one job that is running on one cluster. But in a real case, it should be more complex, they usually use multiple jobs to calculate the data and may use several different type clusters to process it. For example: Raw Data - Job A(Cluster A) - Job B(Cluster B) - Job C(Cluster A) - Result Actually in my opinion, this kind of job could be easy to implement by using Oozie as a workflow engine. But for current EDP, it doesn't implement this kind of complex case. Another concern is about Spark, for Spark it cannot use Oozie to do this. So we need to create an abstract layer to help to implement this kind of scenarios. However, any suggestion is welcome. Thanks. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Enforcing correct short and long description of packages we produce
Okay, how's it fixed? Just updating setup.cfg for each project. Packaging is pretty much a blackbox to me (and I don't think I'm the only one with that view). Letting us know about a problem is great, but a way to resolve this would be even better. Thanks, Steve Martinelli Keystone Core Thomas Goirand z...@debian.org wrote on 03/08/2015 06:51:38 PM: From: Thomas Goirand z...@debian.org To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 03/08/2015 06:57 PM Subject: [openstack-dev] Enforcing correct short and long description of packages we produce Sorry guys, for writing it this way, but really... I'm sick and tired of the absence of relevant short and long description on almost every component we produce. Look at this one: https://pypi.python.org/pypi/oslo.policy Is it so hard to produce 3 lines of long description? Can't we have a rule which enforces no library can graduate with such a poor description? No, that's not *only* about me having to write a correct package description, otherwise risking to be pointed out as careless by other Debian developers. It's also about new comers to OpenStack. Let's imagine an OpenStack newbie. Do you think it's normal that he needs to search for hours in the docs, and sometimes even in the code, just to figure out what the hell a given Oslo lib does? Do you think it makes anyone willing to use a lib, when one has to search for the definition of RBAC? (hint: it's looking like this means Role Based Access Control, but I didn't find out yet what's the difference between RBAC and an ACL...) Really, I don't wish to appear as a moron, but I've been crying about this for at least 2 or 3 years, and I see no progress. I think it's more than time to enforce a rule using a gate test or something to prevent this to happen again. Cheers, Thomas Goirand (zigo) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.
Works for me, but the previous one worked as well. So, consider my vote as +1 unless the majority is against this :) -- Regards, Alexander Tivelkov On Mon, Mar 9, 2015 at 12:36 AM, Fei Long Wang feil...@catalyst.net.nz wrote: Oh, it means 3:00AM for me :-( On 09/03/15 09:07, Nikhil Komawar wrote: Hi all, Currently, we've alternating time for Glance meetings. Now, with the Daylight savings being implemented in some parts of the world, we're thinking of moving the meeting time to just one slot i.e. earlier in the day(night). This solves the original conflicting times issue that a subset of the individuals had; to add to that the schedule is less confusing and unified. So, the new proposal is: Glance meetings [1] to be conducted weekly on Thursdays at 1400UTC [2] on #openstack-meeting-4 This would be implemented on Mar 19th, given there are no major objections. Please vote with +1/-1 here. [1] https://wiki.openstack.org/wiki/Meetings#Glance_Team_meeting [2] http://www.timeanddate.com/worldclock/fixedtime.html?hour=14min=0sec=0 Thanks, -Nikhil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Cheers Best regards, Fei Long Wang (王飞龙) -- Senior Cloud Software Engineer Tel: +64-48032246 Email: flw...@catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington -- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE
+1, I am fan of checking the constraints in the controller level instead of relying on FK constraints itself, thanks. Best Regards, Dave Chen From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com] Sent: Monday, March 09, 2015 2:29 AM To: David Stanek; OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE On March 8, 2015 at 11:24:37 AM, David Stanek (dsta...@dstanek.com) wrote: On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer mba...@redhat.com wrote: can you elaborate on your reasoning that FK constraints should be used less overall? or do you just mean that the client side should be mirroring the same rules that would be enforced by the FKs? I don't think he means that we will use them less. Our SQL backends are full of them. What Keystone can't do is rely on them because not all implementations of our backends support FKs. 100% spot on David. We support implementations that have no real concept of FK and we cannot assume that a cascade (or restrict) will occur on these implementations. —Morga -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek www: http://dstanek.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev smime.p7s Description: S/MIME cryptographic signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Enforcing correct short and long description of packages we produce
Sorry guys, for writing it this way, but really... I'm sick and tired of the absence of relevant short and long description on almost every component we produce. Look at this one: https://pypi.python.org/pypi/oslo.policy Is it so hard to produce 3 lines of long description? Can't we have a rule which enforces no library can graduate with such a poor description? No, that's not *only* about me having to write a correct package description, otherwise risking to be pointed out as careless by other Debian developers. It's also about new comers to OpenStack. Let's imagine an OpenStack newbie. Do you think it's normal that he needs to search for hours in the docs, and sometimes even in the code, just to figure out what the hell a given Oslo lib does? Do you think it makes anyone willing to use a lib, when one has to search for the definition of RBAC? (hint: it's looking like this means Role Based Access Control, but I didn't find out yet what's the difference between RBAC and an ACL...) Really, I don't wish to appear as a moron, but I've been crying about this for at least 2 or 3 years, and I see no progress. I think it's more than time to enforce a rule using a gate test or something to prevent this to happen again. Cheers, Thomas Goirand (zigo) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] [Glance] Nomination for glance-stable-maint
Zhi Yan is all set now. Welcome ! Nikhil Komawar wrote: Thank you, Thierry! -Nikhil From: Thierry Carrez thie...@openstack.org Sent: Tuesday, March 3, 2015 10:26 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [stable] [Glance] Nomination for glance-stable-maint Nikhil Komawar wrote: I would like to propose Zhi Yan Liu for the role of stable maintainer for Glance program. I'll reach out to Zhi Yan to make sure he is aware of the stable branch policy[1], then proceed to add him. [1] https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy Cheers, -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Generic question about synchronizing neutron agent on compute node with DB
Port changes will result in an update message being sent on the AMQP message bus. When the agent receives it, it will affect the communications then. If that notification is lost, the agent will eventually resynchronize. So during normal operations, the change should take effect within a few seconds. On Sat, Mar 7, 2015 at 4:10 AM, Leo Y minh...@gmail.com wrote: Hello, What happens when neutron DB is updated to change network settings (e.g. via Dashboard or manually) when there are communication sessions opened in compute nodes. Does it influence those sessions? When the update is propagated to compute nodes? Thank you __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Thinking about our python client UX
I agree, we need a discussion asap. I think below things can mitigate the unexpected behavior of python client and this is borrow from object model. 1. Python client should have its own version and attributes like supported api version. 2. It should be able to recognize the server's version and show corresponding fields instead of all. B.R Tan -Original Message- From: Devananda van der Veen [mailto:devananda@gmail.com] Sent: Sunday, March 8, 2015 8:12 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [Ironic] Thinking about our python client UX Hi folks, Recently, I've been thinking more of how users of our python client will interact with the service, and in particular, how they might expect different instances of Ironic to behave. We added several extensions to the API this cycle, and along with that, also landed microversion support (I'll say more on that in another thread). However, I don't feel like we've collectively given nearly enough thought to the python client. It seems to work well enough for our CI testing, but is that really enough? What about user experience? In my own testing of the client versioning patch that landed on Friday, I noticed some pretty appalling errors (some unrelated to that patch) when pointing the current client at a server running the stable/juno code... http://paste.openstack.org/show/u91DtCf0fwRyv0auQWpx/ I haven't filed specific bugs from yet this because I think the issue is large enough that we should talk about a plan first. I think that starts by agreeing on who the intended audience is and what level of forward-and-backward compatibility we are going to commit to [*], documenting that agreement, and then come up with a plan to deliver that during the L cycle. I'd like to start the discussion now, so I have put it on the agenda for Monday, but I also expect it will be a topic at the Vancouver summit. -Devananda [*] full disclosure I believe we have to commit to building a client that works well with every release since Icehouse, and the changes we've introduced in the client in this cycle do not. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Core nominations.
On 07/03/15 23:16 +, Nikhil Komawar wrote: Thank you for the response, Hemanth! Those are some excellent questions. In order to avoid diverging the conversation, I would like to give my general sense of direction. Please do keep in mind that a lot of these thoughts need to be better formulated, preferably on a different thread. Core-members would be generic concept unlike core-reviewers. The one important thing that this should achieve is clear understanding of the individuals (usually ones who are new or interact less often in Glance) - who actually is a Core in the program? There are a few things that can be part of their rights like being able to vote for important decisions (like the current thread), they may or may not have core-reviewer rights based on their participation area. For example, they could be security liaison or they may _officially_ do release management for the libraries without being a core-reviewer, etc. The responsibilities should complement the rights. Those are just initial thoughts and can be better formulated. I will attempt to craft out the details of the core-member concept in the near future and you all are welcome to join me in doing so. I think I misread the original proposal with ragards to core-members. As it is explained here, I'm opposed on having this. As soon as you start tagging people and adding more layers to the community, it'll be harder to manage it and more importantly it'll be more fragmented than it is, which is something I believe we don't need. Citing the example you mentioned in your previous email: There are a few things that can be part of their rights like being able to vote for important decisions This breaks openess and it reads like: If you're not a 'core-member', your vote won't count We've fought hard to remove all these kind of labels and exclusive rights by reducing them to the minimum, hence the core-reviewers team. Anyone should feel free to vote, speak up and most importantly, everyones opinion *must* be taken into account. I'll wait for your final proposal to give a more constructive and extended opinion based on that. Flavio Hope that answered your questions, at least for the time being! Cheers -Nikhil ━━━ From: Hemanth Makkapati hemanth.makkap...@rackspace.com Sent: Friday, March 6, 2015 7:15 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. I like the idea of a 'core-member'. But, how are core-members different from core-reviewers? For instance, with core-reviewers it is very clear that these are folks you would trust with merging code because they are supposed to have a good understanding of the overall project. What about core-members? Are core-members essentially just core-reviewers who somehow don't fit the criteria of core-reviewers but are good candidates nevertheless? Just trying to understand here ... no offense meant. Also, +1 to both the criteria for removing existing cores and addition of new cores. -Hemanth. ━━━ From: Nikhil Komawar nikhil.koma...@rackspace.com Sent: Friday, March 6, 2015 4:04 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. Thank you all for the input outside of the program: Kyle, Ihar, Thierry, Daniel! Mike, Ian: It's a good idea to have the policy however, we need to craft one that is custom to the Glance program. It will be a bit different to ones out there as we've contributors who are dedicated to only subset of the code - for example just glance_store or python-glanceclient or metadefs. From here on, we may see that for Artifacts and other such features. It's already being observed for metadefs. While I like Mike's suggestion to (semi-)adopt what Nova and Neutron are doing, it also makes me wonder if that's going to help us in long term. If not, then what can we do now to set a good path forward? Flavio, Erno, Malini, Louis, Mike: Drafting a guideline policy and implementing rotation based on that was my intent so that everyone is aware of the changes in the program. That would let the core reviewers know what their duties are and let non-cores know what they need to do to become cores. Moreover, I've a idea for proposing a core-member status for our program than just core-reviewer. That seems more applicable for a few strong regular contributors like Travis and Lakshmi who work on bug fixes, bug triaging and client improvements however, do not seem to keep momentum on reviews. The core status can affect project decisions hence, this change may be important. This process may involve some interactions with governance so, will take more time. Malini: I wish to take a strategic decision here rather an agile one. That needs a lot of brainpower before implementation.
Re: [openstack-dev] [neutron] Neutron agent internal data structures
Thank you. I am looking to read this state and compare it with neutron DB. If there are agents that do it already, I would like only to learn if I can change the polling period. Can you advise about the most efficient way to learn which agent does it and which doesn't? Leonid On Sun, Mar 8, 2015 at 12:02 AM, Salvatore Orlando sorla...@nicira.com wrote: Hi Leo, Every agent keeps anyway an in-memory state throughout its execution. The agents indeed have no persistent storage - at least not in the usual form of a database. They however rely on data other than the neutron database. For instance for the l2 agent, ovsdb itself is a source of information. The agent periodically scans it to detect interfaces which are brought up or down. As another example the dhcp agent stores its current state a 'data' directory (if you're using devstack it's usually /opt/stack/data/neutron/dhcp) Hope this helps, Salvatore On 7 March 2015 at 13:05, Leo Y minh...@gmail.com wrote: Hello, Where within the code of neutron agents I can find structure(s) that store network information? The agent has to know all current networks and ports in use by all VMs that are running in its compute node. Does anyone know where this information is stored except for neutron DB? Thank you __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards, Leo - I enjoy the massacre of ads. This sentence will slaughter ads without a messy bloodbath __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it
On 18/02/15 10:07 -0500, Doug Hellmann wrote: On Wed, Feb 18, 2015, at 05:40 AM, Daniel P. Berrange wrote: On Tue, Feb 17, 2015 at 09:29:19AM -0800, Clint Byrum wrote: Excerpts from Daniel P. Berrange's message of 2015-02-17 02:37:50 -0800: On Wed, Feb 11, 2015 at 03:14:39PM +0100, Stefano Maffulli wrote: ## Cores are *NOT* special At some point, for some reason that is unknown to me, this message changed and the feeling of core's being some kind of superheros became a thing. It's gotten far enough to the point that I've came to know that some projects even have private (flagged with +s), password protected, irc channels for core reviewers. This is seriously disturbing. If you're one of those core reviewers hanging out on a private channel, please contact me privately: I'd love to hear from you why we failed as a community at convincing you that an open channel is the place to be. No public shaming, please: education first. I've been thinking about these last few lines a bit, I'm not entirely comfortable with the dynamic this sets up. What primarily concerns me is the issue of community accountability. A core feature of OpenStack's project individual team governance is the idea of democractic elections, where the individual contributors can vote in people who they think will lead OpenStack in a positive way, or conversely hold leadership to account by voting them out next time. The ability of individuals contributors to exercise this freedom though, relies on the voters being well informed about what is happening in the community. If cases of bad community behaviour, such as use of passwd protected IRC channels, are always primarily dealt with via further private communications, then we are denying the voters the information they need to hold people to account. I can understand the desire to avoid publically shaming people right away, because the accusations may be false, or may be arising from a simple mis-understanding, but at some point genuine issues like this need to be public. Without this we make it difficult for contributors to make an informed decision at future elections. Right now, this thread has left me wondering whether there are still any projects which are using password protected IRC channels, or whether they have all been deleted, and whether I will be unwittingly voting for people who supported their use in future openstack elections. Shaming a person is a last resort, when that person may not listen to reason. It's sometimes necessary to bring shame to a practice, but even then, those who are participating are now draped in shame as well and will have a hard time saving face. This really isn't about trying to shame people, rather it is about having accountability in the open. If the accusations of running private IRC channels were false, then yes, it would be an example of shaming to then publicise those who were accused. Since it is confirmed that private password protected IRC channels do in fact exist, then we need to have the explanations as to why this was done be made in public. The community can then decide whether the explanations offered provide sufficient justification. This isn't about shaming, it is about each individual being able to decide for themselves as to whether what happened was acceptable, given the explanations. Right. And Stef is pulling that information together from the appropriate sources. Sometimes it's easier to have those sorts of conversations one-on-one than in a fully public forum. When we have the full picture, then will know whether further action is needed (I hope the team decides to close down the channel on their own, for example). In any case, we will publish the facts. But let's give Stef time to work on it, first. Hi All, I'm pretty sure this was discussed already in a TC meeting, which I did not attend unfortunately. In the spite of keeoing things open - not only the issues but also the solutions found - would someone from the TC (or Stefano) mind highlighting what the resolution for this issue is? I don't think there's a great solution for the per-project organizational issues other than recommending people to work in the open and having the community fighting for it. However, I do expect there to be a solution for the secret channel, which by the way still exists. Thank you all for participating in this discussion, Flavio Doug Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?
Thanks for Jay point this out! If we have agreement on this and document it, that will be great for guiding developer how to add new API. I know we didn't want extension for API. But I think we still need modularity. I don't think we should put everything in a single file, that file will become huge in the future and hard to maintenance. We can make the 'extension' not configurable. Replace 'extension' with another name, deprecate the extension info api int he future But that is not mean we should put everything in a file. For modularity, we need define what should be in a separated module(it is extension now.) There are three cases: 1. Add new resource This is totally worth to put in a separated module. 2. Add new sub-resource like server-tags, I prefer to put in a separated module, I don't think put another 100 lines code in the servers.py is good choice. 3. extend attributes and methods for a existed resource like add new attributes for servers, we can choice one of existed module to put it in. Just like this patch https://review.openstack.org/#/c/155853/ But for servers-tags, it's sub-resource, we can put it in its-own module. If we didn't want to support extension right now, we can begin from not show servers-tags in extension info API first. That means extension info is freeze now. We deprecated the extension info api in later version. Thanks Alex 2015-03-08 8:31 GMT+08:00 Jay Pipes jaypi...@gmail.com: Hi Stackers, Now that microversions have been introduced to the Nova API (meaning we can now have novaclient request, say, version 2.3 of the Nova API using the special X-OpenStack-Nova-API-Version HTTP header), is there any good reason to require API extensions at all for *new* functionality. Sergey Nikitin is currently in the process of code review for the final patch that adds server instance tagging to the Nova API: https://review.openstack.org/#/c/128940 Unfortunately, for some reason I really don't understand, Sergey is being required to create an API extension called os-server-tags in order to add the server tag functionality to the API. The patch implements the 2.4 Nova API microversion, though, as you can see from this part of the patch: https://review.openstack.org/#/c/128940/43/nova/api/ openstack/compute/plugins/v3/server_tags.py What is the point of creating a new plugin/API extension for this new functionality? Why can't we just modify the nova/api/openstack/compute/server.py Controller.show() method and decorate it with a 2.4 microversion that adds a tags attribute to the returned server dictionary? https://github.com/openstack/nova/blob/master/nova/api/ openstack/compute/servers.py#L369 Because we're using an API extension for this new server tags functionality, we are instead having the extension extend the server dictionary with an os-server-tags:tags key containing the list of string tags. This is ugly and pointless. We don't need to use API extensions any more for this stuff. A client knows that server tags are supported by the 2.4 API microversion. If the client requests the 2.4+ API, then we should just include the tags attribute in the server dictionary. Similarly, new microversion API functionality should live in a module, as a top-level (or subcollection) Controller in /nova/api/openstack/compute/, and should not be in the /nova/api/openstack/compute/plugins/ directory. Why? Because it's not a plugin. Why are we continuing to use these awkward, messy, and cumbersome API extensions? Please, I am begging the Nova core team. Let us stop this madness. No more API extensions. Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Do No Evil
On 03/08/2015 06:34 PM, Mike Bayer wrote: Ian Wells ijw.ubu...@cack.org.uk wrote: With apologies for derailing the question, but would you care to tell us what evil you're planning on doing? I find it's always best to be informed about these things. All of us, every day, do lots of things that someone is going to think is evil. From eating meat, to living various kinds of lifestyles, to supporting liberal or conservative causes, to just living in a certain country, to using Windows or other “non-free” operating systems, to top-posting, makes you evil to someone; to lots of people, in fact. This is why a blanket statement like “do no evil” is pretty much down to two choices, A. based on some arbitrary, undefined notion of “evil” in which case nobody can use the software, or B. based on the user’s own subjective view of “evil” which means the phrase is just a humorous frill. Maybe authors add this phrase as a means to limit the use of their software only to those communities where such a statement is patently ridiculous (e.g., not publicly held corporations). but also given that “evil” can be almost anything, I don’t think it’s reasonable that users would have to report on their intended brand of “evil”. tl;dr: Debian considers the do no evil license non-free. I second the above. Also, because the above (ie: it's impossible to clearly define what evil means), but also because we have all decided to not discriminate any kind of use or users (even the most evil ones), Debian consider the do no evil licensing as non-free (and therefore, not fit for an upload in Debian main). We have contacted the Json.org author multiple times, and never we had a positive reply, only some jokes (like: Oh, do you really want to do evil? kinds of reply). To illustrate how stupid the do no evil license is, let me provide another example of a stupid license. It's called the dontbeadick license, and it is a real life example. We use it in Debian to train wanabe Debian Developers (asking them to comment this license). [Please don't be offended when reading the license below, I'm not the author of these lines, and I would have preferred that this license never existed.] DON'T BE A DICK PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 1. Do whatever you like with the original work, just don't be a dick. Being a dick includes - but is not limited to - the following instances: 1a. Outright copyright infringement - Don't just copy this and change the name. 1b. Selling the unmodified original with no work done what-so-ever, that's REALLY being a dick. 1c. Modifying the original work to contain hidden harmful content. That would make you a PROPER dick. 2. If you become rich through modifications, related works/services, or supporting the original work, share the love. Only a dick would make loads off this work and not buy the original work's creator(s) a pint. 3. Code is provided with no warranty. Using somebody else's code and bitching when it goes wrong makes you a DONKEY dick. Fix the problem yourself. A non-dick would submit the fix back. While this might look fun to begin with, in fact, it is not. If you look closer, this license restricts the rights to: - fork (1a: renaming without change) - redistribute (1.b: selling without work) - modify (1c: you can't add hidden harmful content) - modify (again) (2.: you must buy beer to the original author) Besides this, the examples in the first sections are just examples, and the restrictions is not limited to them. At the end, IMO the author of the license is really what he doesn't want others to be: he tried to be funny, but it's not funny at all. Think a 2nd time, and apply the same kinds of reasoning to the do no evil licensing. It's a similar approach, which makes the whole license non-free. It's just not as much obvious when reading it as with the don't be a dick license, but it's the same problem: it restricts the rights to use the software as it pleases you, which makes the software non-free (restriction of the use of the software to only non-evil use). In Debian, the DFSG states [1]: 5. The license must not discriminate against any person or group of persons. 6. The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. The JSLint license is discriminating against the evil group, and discriminate against evil use. The do no evil section of the JSLint license doesn't respect what every Debian Developer has signed for (ie: the DFSG), and is therefore not fit for an upload in Debian. Let's be more specific now, just for fun... What if I believe jslint is being evil with me, because it votes no to my patches? Last thing: in USA, there's the 2nd
Re: [openstack-dev] [neutron] How neutron calculate routing path
The L3 agent uses ARP and static routes like a normal router would. The L2 agent is where there might be differences depending on the network type used. If it's a tunnel overlay, the L2 agent may perform an ARP offload from information it has learned via the L2 population mechanism. On Sat, Mar 7, 2015 at 4:02 AM, Leo Y minh...@gmail.com wrote: Hello, I am looking to learn how neutron agent (probably L3) calculates a new routing path when VM on compute node wants to communicate with some destination. Does it use neutron API to learn about network topology or it uses its internal structures to simulate path resolving like in real network? If the latter is correct, then what happens when a network topology is changed in neutron DB (due user intervention for by other actions) and the local data is invalid? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Glance K-3 reviews.
Thanks Nikhil, To have a single whiteboard for all the Artifacts reviews we've created an etherpad [1] Here we track the progress of all the 7 artifact-releated changesets and all the unresolved issues found there. As agreed earlier, non-critical issues (i.e. the issues which do not affect performance, security, API compatibility and do not cause HTTP 500 errors) should not block the review process: we log that issues in the etherpad to be fixed later as independent bugfix changesets or to be additionally discussed if such need exists. The critical ones are going to be fixed ASAP, of course. We are copying all the comments from reviews to that etherpad, but if you wish, please feel free to put notes there on your own if it is more convenient for you. Thanks for your reviews and feedback! [1] https://etherpad.openstack.org/p/Artifacts_Reviews -- Regards, Alexander Tivelkov On Sun, Mar 8, 2015 at 10:36 PM, Nikhil Komawar nikhil.koma...@rackspace.com wrote: Hi all, This is a gentle reminder on the ML regarding Kilo-3 related reviews. Similar announcements have been made in the past few weeks during the Glance meetings [2]. A small summary of what the current status looks like for k-3 Glance: 1. Feature freeze for Glance is Mar 12th. 2. [1] has the list of specs/BPs targeted for Kilo. (They are also our priorities for this cycle). 3. [1] should also give information regarding what needs to be reviewed. Many of the specs have a mature enough code; and a little chance for them to need major feedback. So, they are basically waiting on core reviewers to show up. 4. Please prefer to review specs over bugs at the moment as we can target bugs after Mar 12th before official freeze on Mar 19th (and some others during the RCs). 5. Only Artifacts, Catalog Index Service and Deactivate an Image specs have been proposed for possible FFE candidates (based on the momentum they have been having in discussions and commitment of members to get issues resolved). 6. We are planning to do a release of the client and store lib before the official freeze for accommodating some of the features. 7. If you need more details, please refer to [2] and look for logs of meetings on or after Feb 12th for K3 related updates. If you still have questions, then feel free to reach out. Please remember this is a busy period so, turn around time will be more. P.S. As some of the reviewers (and core-reviewers like Flavio and Zhi Yan) are not able to make it to the meetings often, this is a special announcement being made for their convenience. [1] https://launchpad.net/glance/+milestone/kilo-3 [2] http://eavesdrop.openstack.org/meetings/glance/2015/ Thanks, -Nikhil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it
On 2015-03-08 08:20:31 -0430 (-0430), Flavio Percoco wrote: I'm pretty sure this was discussed already in a TC meeting, which I did not attend unfortunately. In the spite of keeoing things open - not only the issues but also the solutions found - would someone from the TC (or Stefano) mind highlighting what the resolution for this issue is? [...] http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-02-24-20.02.log.html#l-107 https://review.openstack.org/159930 -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Core nominations.
On 3/8/15, 2:34 PM, Flavio Percoco fla...@redhat.com wrote: On 07/03/15 23:16 +, Nikhil Komawar wrote: Thank you for the response, Hemanth! Those are some excellent questions. In order to avoid diverging the conversation, I would like to give my general sense of direction. Please do keep in mind that a lot of these thoughts need to be better formulated, preferably on a different thread. Core-members would be generic concept unlike core-reviewers. The one important thing that this should achieve is clear understanding of the individuals (usually ones who are new or interact less often in Glance) - who actually is a Core in the program? There are a few things that can be part of their rights like being able to vote for important decisions (like the current thread), they may or may not have core-reviewer rights based on their participation area. For example, they could be security liaison or they may _officially_ do release management for the libraries without being a core-reviewer, etc. The responsibilities should complement the rights. Those are just initial thoughts and can be better formulated. I will attempt to craft out the details of the core-member concept in the near future and you all are welcome to join me in doing so. I think I misread the original proposal with ragards to core-members. As it is explained here, I'm opposed on having this. As soon as you start tagging people and adding more layers to the community, it'll be harder to manage it and more importantly it'll be more fragmented than it is, which is something I believe we don't need. Agree 100% Citing the example you mentioned in your previous email: There are a few things that can be part of their rights like being able to vote for important decisions This breaks openess and it reads like: If you're not a 'core-member', your vote won't count We've fought hard to remove all these kind of labels and exclusive rights by reducing them to the minimum, hence the core-reviewers team. Anyone should feel free to vote, speak up and most importantly, everyones opinion *must* be taken into account. I'll wait for your final proposal to give a more constructive and extended opinion based on that. Flavio Hope that answered your questions, at least for the time being! Cheers -Nikhil ━ ━━ From: Hemanth Makkapati hemanth.makkap...@rackspace.com Sent: Friday, March 6, 2015 7:15 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. I like the idea of a 'core-member'. But, how are core-members different from core-reviewers? For instance, with core-reviewers it is very clear that these are folks you would trust with merging code because they are supposed to have a good understanding of the overall project. What about core-members? Are core-members essentially just core-reviewers who somehow don't fit the criteria of core-reviewers but are good candidates nevertheless? Just trying to understand here ... no offense meant. Also, +1 to both the criteria for removing existing cores and addition of new cores. -Hemanth. ━ ━━ From: Nikhil Komawar nikhil.koma...@rackspace.com Sent: Friday, March 6, 2015 4:04 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. Thank you all for the input outside of the program: Kyle, Ihar, Thierry, Daniel! Mike, Ian: It's a good idea to have the policy however, we need to craft one that is custom to the Glance program. It will be a bit different to ones out there as we've contributors who are dedicated to only subset of the code - for example just glance_store or python-glanceclient or metadefs. From here on, we may see that for Artifacts and other such features. It's already being observed for metadefs. While I like Mike's suggestion to (semi-)adopt what Nova and Neutron are doing, it also makes me wonder if that's going to help us in long term. If not, then what can we do now to set a good path forward? Flavio, Erno, Malini, Louis, Mike: Drafting a guideline policy and implementing rotation based on that was my intent so that everyone is aware of the changes in the program. That would let the core reviewers know what their duties are and let non-cores know what they need to do to become cores. Moreover, I've a idea for proposing a core-member status for our program than just core-reviewer. That seems more applicable for a few strong regular contributors like Travis and Lakshmi who work on bug fixes, bug triaging and client improvements however, do not seem to keep momentum on reviews. The core status can affect project decisions hence, this change may be important. This process may involve some interactions with governance so, will take more time. Malini: I wish to take a strategic decision here
