Re: [openstack-dev] Which service is using port 8778?
On Tue, Dec 20, 2016 at 4:46 PM, Ghanshyam Mann < ghanshyam.m...@nectechnologies.in> wrote: [snip] > But OpenStack port used by services are maintained here[3], may be it will > be good for each project to add their port in this list. > [snip] > ..[3] http://docs.openstack.org/newton/config-reference/ > firewalls-default-ports.html I know this thread has moved on, but I'm not sure a list of default ports for a firewall is the right place to be documenting this. If there are admin services that perhaps should not, by default, be exposed publicly - then they shouldn't be listed in such a table. A simple implementation might be to expose all of these, which would not be the most secure default. Perhaps the equivalent of /etc/services or http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml specifically for OpenStack might be better. Hope this helps, Michael... -- Michael Davies mich...@the-davies.net Rackspace Cloud Builders Australia __ 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][elections] Results of the TC Election
Thank you Tony, Tristan and Nate for serving our community by performing this often-thankless task! -- Michael Davies mich...@the-davies.net Rackspace Cloud Builders Australia __ 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] static Portgroup support.
Thank you for creating these videos, they are great and certainly help my understanding! Michael... On Tue, Aug 9, 2016 at 5:58 PM, Vasyl Saienko <vsaie...@mirantis.com> wrote: > Hello Ironic'ers! > > We've recorded a demo that shows how static portgroup works at the moment: > > Flat network scenario: https://youtu.be/vBlH0ie6Lm4 > Multitenant network scenario: https://youtu.be/Kk5Cc_K1tV8 > > Sincerely, > Vasyl Saienko > > On Tue, Jul 19, 2016 at 3:30 PM, Vasyl Saienko <vsaie...@mirantis.com> > wrote: > >> Hello Community, >> >> Current portgroup scenario is not fully clear for me. The related spec >> [3] doesn't clearly describe it. And based on implementation [1] and [2] I >> guess it should work in the following fashion for node with 3 NICs, where >> eth1 and eth2 are members of Porgroup Po0/1 >> >> Node network connection info: >> eth1 (aa:bb:cc:dd:ee:f1) <---> Gig0/1 >> eth2 (aa:bb:cc:dd:ee:f2) <---> Gig0/2 >> eth3 (aa:bb:cc:dd:ee:f3) <---> Gig0/3 >> >> For FLAT network scenario: >> 1. Administrator enrol ironic node. >> 2. Administrator creates a 3 ports for each interface, and a portgroup >> that contains eth0 and eth1 ports. >> 3. The ports Gig0/1 and Gig0/2 are added to portgroup Po0/1 manually on >> the switch. >> 4. When user request to boot an instance, Nova randomly picks interface >> [2], it might be a portgroup or single NIC interface. Proposed change [1] >> do not allow to specify what exactly network type we would like to use >> single NIC or portgroup. >> >> For multitenancy case: >> All looks the same, in addition administrator adds local_link_connection >> information for each port (local_link_connection 'port_id' field is >> 'Gig0/1' for eth1, 'Gig0/2' for eth2 and 'Gig0/3' for eth3, ). Ironic send >> this information to Neutron who plugs ports to needed network. >> >> The same user-scenario is available at the moment without any changes to >> Nova or Ironic. The difference is that administrator creates one port for >> single interface eth3 with local_link_connection 'port_id'='Gig0/3', and a >> port that is a logical representation of portgroup (eth1 and eth2) with >> local_link_connection 'port_id'='Po0/1'. >> >> Please let me know if I've missed something or misunderstood current >> portgroup scenario. >> >> Reference: >> [0] https://review.openstack.org/206163 >> [1] https://review.openstack.org/332177 >> [2] https://github.com/openstack/nova/blob/06c537fbe5bb4ac5a3012 >> 642c899df815872267c/nova/network/neutronv2/api.py#L270 >> [3] https://specs.openstack.org/openstack/ironic-specs/specs/not >> -implemented/ironic-ml2-integration.html >> > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Michael Davies mich...@the-davies.net Rackspace Cloud Builders Australia __ 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] Trello board
On Sat, Jun 4, 2016 at 1:09 AM, Jim Rollenhagen <j...@jimrollenhagen.com> wrote: > Myself and some other cores have had trouble tracking our priorities > using Launchpad and friends, so we put together a Trello board to help > us track it. This should also help us focus on what to review or work > on. > > https://trello.com/b/ROTxmGIc/ironic-newton-priorities Thanks Jim for sharing that link. Anything to help keep things organised :) -- Michael Davies mich...@the-davies.net Rackspace Australia __ 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] [nova][stable] Proposal to add Tony Breeds to nova-stable-maint
Congrats Tony! -- Michael Davies mich...@the-davies.net Rackspace Cloud Builders Australia __ 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] Do we need to have a mid-cycle?
On Tue, Nov 17, 2015 at 12:35 AM, Jim Rollenhagen <j...@jimrollenhagen.com> wrote: > > > My preference is 4) no mid-cycle -- and try to work more effectively with > > people in different locations and time zones. > > ++ that was part of my thought process when I proposed not having an > official midcycle. > Thanks for that. > Another idea I floated last week was to do a virtual midcycle of sorts. > Treat it like a normal midcycle in that everyone tells their management > "I'm out for 3-4 days for the midcycle", but they don't travel anywhere. > We come up with an agenda, see if there's any planning/syncing work to > do, or if it's all just hacking on code/reviews. > > Then we can set up some hangouts (or similar) to get people in the same > "room" working on things. Time zones will get weird, but we tend to > split into smaller groups at the midcycle anyway; this is just more > timezone-aligned. We can also find windows where time zones overlap when > we want to go across those boundaries. Disclaimer: people may need to > work some weird hours to do this well. > > I think this might get a little bit bumpy, but if it goes relatively > well we can try to improve on it for the future. Worst case, it's a > total failure and is roughly equivalent to the "no midcycle" option. I'm happy to give it a try. Thanks for exploring new options jroll! -- Michael Davies mich...@the-davies.net Rackspace Cloud Builders Australia __ 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] Do we need to have a mid-cycle?
On Wed, Nov 11, 2015 at 3:15 AM, Lucas Alvares Gomes <lucasago...@gmail.com> wrote: > > So, what people think about it? Should we have a mid-cycle for the > Mitaka release or not? If so, what format should we use? > I like the idea of having a midcycle as it's a useful sync point, so my preference would be: 3. Coordinated regional mid-cycles (which probably means North America over Europe for those in the Antipodes) 1. Normal mid-cycle 2. Virtual mid-cycle 4. Not having a mid-cycle at all I find value in them, due to timezone challenges, but I'm probably unique in this case. -- Michael Davies mich...@the-davies.net Rackspace Cloud Builders Australia __ 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] [Nova] notification subteam
On Wed, Nov 4, 2015 at 8:49 AM, Michael Still <mi...@stillhq.com> wrote: > I'd be interested in being involved with this, and I know Paul Murray is > interested as well. > > I went to make a doodle, but then realised the only non-terrible timeslot > for Australia / UK / US Central is 8pm UTC (7am Australia, 8pm London, 2pm > Central US). So what do people think of that time slot? > I'm interested along with Mario about making sure Ironic and Nova notifications follow similar paths, so I'd probably lurk along to this as well (so the proposed time slot works for me). -- Michael Davies mich...@the-davies.net Rackspace Cloud Builders Australia __ 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] Stepping down from IPA core
On Tue, Sep 22, 2015 at 1:19 AM, Josh Gachnang <j...@pcsforeducation.com> wrote: > Hey y'all, it's with a heavy heart I have to announce I'll be stepping > down from the IPA core team on Thurs, 9/24. I'm leaving Rackspace for a > healthcare startup (Triggr Health) and won't have the time to dedicate to > being an effective OpenStack reviewer. > Thanks Josh for everything you've done! I've really appreciated how you're always upbeat - we'll miss having your around. All the best for the new adventure, Michael... -- Michael Davies mich...@the-davies.net Rackspace Cloud Builders Australia __ 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] [Ironic][Nova] The process around the Nova Ironic driver
Hey Everyone, John Villalovos and I have been acting as the Nova-Ironic liaisons, which mostly means dealing with bugs that have been raised against the Ironic driver in Nova. So you can understand what we’ve been doing, and how you can help us do that job better, we’re writing this email to clarify the process we’re following. Weekly Bug Scrub: Each week (Tuesday 2300 UTC) John and Michael meet to go through the results of this query https://bugs.launchpad.net/nova/+bugs?field.tag=ironicorderby=-idstart=0 to find bugs that we don’t know about, to see what progress has been happening, and to see if there’s any direct action that needs to be taken. We record the result of this triage over here https://wiki.openstack.org/wiki/Nova-Ironic-Bugs Fix Bugs: If we are able, and have the capacity, we try and fix bugs ourselves. Where we need it, we seek help from both the Nova and/or Ironic communities. But finding people to help fix bugs in the Nova Ironic driver is probably an area we can do better at (*hint* *hint*) Review Bugs: Once fixes are proposed, we solicit reviews for these fixes. Once we’re happy that the proposed solution isn’t completely bonkers, one of us will +1 that review, and add it to the list of Nova bugs that need review by Nova: https://etherpad.openstack.org/p/liberty-nova-priorities-tracking Attend the Nova team meeting: One of us will attend the weekly IRC meeting to represent the Ironic team interests within Nova. Nova might want to discuss new requirements they have on drivers, or to discuss a bug that has been raised, or to find out, or to communicate, which bugs the other team feel are important to be addressed before the ever-looming next release. Attend the Ironic team Meeting: John will attend the weekly IRC meeting to raise any issues with the broader team that we become aware of. It might be that a new bug has been raised and we need to find someone willing to take it on, or it may be that an existing bug with a proposed change is languishing due to a lack of reviews (Michael can’t do that as 2:30am local time is just a little wrong for an IRC meeting :) So there it is, that's how the Ironic team are supporting the Ironic driver in Nova. If you have any questions, or just want to dive in and fix bugs raised against the driver, you’re most welcome to get in touch - on IRC I’m ‘mrda’ and John is ‘jlvillal‘ :) Michael… -- Michael Davies mich...@the-davies.net Rackspace Cloud Builders Australia __ 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] Was there a meeting yesterday (August 4, 2015 at 0500 UTC)
Only a few people turned up (including me who was late) so no meeting was held. Hope this helps, Michael... On Wed, Aug 5, 2015 at 10:43 PM, Ruby Loo rlooya...@gmail.com wrote: Hi, Was there an ironic meeting yesterday (August 4, 2015 at 0500 UTC)? I don't see any meeting logs from then. --ruby __ 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 -- Michael Davies mich...@the-davies.net Rackspace Cloud Builders Australia __ 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] Let's talk about API versions
On Tue, Jul 28, 2015 at 6:05 AM, Jim Rollenhagen j...@jimrollenhagen.com wrote: [snip] It seems to me we have a few options here: 1) Default the python client and CLI to the earliest supported version. This will never break users by default. 2) Default the python client and CLI to use the special version 'latest'. This will always use the latest API version, and always break people when a new server version (that is not backwards compatible) is deployed. 3) Do what Nova does[1]. Default CLI to latest and python client to earliest. This assumes that CLI is typically used for one-time commands (and it isn't a big deal if we break a one-off command once), and the python client is used for applications. 4) Require a version to use the client at all. This would be a one-time break with how applications initialize the client (perhaps we could fall back to the earliest version or something for a deprecation period). This isn't a great user experience, however, it's the best way to get users to think about versioning. And no, this requires typing another argument every time! is not a valid argument against this; we already require a number of arguments, anyone sane doesn't type --ironic-api-url or --os-username every time they use the client. 5) Do what we're doing now. Bump the client's default version with every release. This mostly hides these versions from end users, and in general those users probably won't know they exist. And then we run into arguments every time we want to make a breaking change to the API. :) I think I like option 1 or 3 the best. I certainly don't like option 5 because we're going to break users every time we release a new client. What do other folks think we should do? Thanks jroll for bringing this up! Isn't the problem here that we're treating breaking and non-breaking changes similarly? Didn't we previously say that major backward incompatible changes should require a major version bump? What if we adopted a semver or similar scheme for API versioning? What if we required 'Major' (in Major.Minor.Patch) to increment for a backwards incompatible change? In our current tooling this would be hard, but is it what we should be doing? Is this the root of the problem? I think we want the latest version of the API, used by the client and server, that is backwards compatible i.e. min(latest client version, latest server version). As developers we want the latest version of our code out there. As operators and users we want the latest (backward compatible) features and the bug fixes, but we don't want to rewrite how we interface to the software. But if a version is explicitly specified, that should be used instead i.e. we should support version pining so that operators can gracefully upgrade when it's right for them (assuming the server still supports that version) But the question remains, What version of the API do we want to ship when we ship a major Ironic release? (whenever that is now[1] :-P ) Or phrased differently, How do we advance versions from release to release?. I think the answer to this is that we default to the latest stable major API version at the point of release. That should be the default for client and server, and shouldn't discount anyone from using older clients with newer servers and vice versa due to the presence of version negotiation. Hope this helps, Michael... [1] https://github.com/openstack/ironic-specs/blob/master/specs/liberty/feature-based-releases.rst -- Michael Davies mich...@the-davies.net Rackspace Cloud Builders Australia __ 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] [Inspector] Addition to ironic-inspector-core, switching to 2x +2 rule
Great news Yuiko! On Wed, Jul 1, 2015 at 6:26 PM, Dmitry Tantsur dtant...@redhat.com wrote: Hi all! Please welcome Yuiko Takada to ironic-inspector-core team. Yuiko has been with the team for some time already. She did substantial work on porting ironic-inspector to Oslo libraries and on our new devstack gate job. Thanks Yuiko, it's a pleasure to work with you. As our core team grows, I'd like us to try to stick with 2x +2 rules. Up to now it was mostly Dmitry approves everything rule, now let us make sure we have at least 2 +2 on a patch before merging it, unless it's critical for release or fixing gate. Don't wait for me to W+1 if you see that patch already has 2x +2. I'd ask the core team to review all the incoming patches. Once our devstack gate is finally working, review will be a lot easier. Cheers, Dmitry -- Michael Davies mich...@the-davies.net Rackspace Cloud Builders Australia __ 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] [api][nova][ironic] Microversion API HTTP header
On Tue, Jun 16, 2015 at 5:15 AM, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote: Given the disagreement evinced by the responses to this thread, let me ask a question: Would there be any particular problem with using X-OpenStack-API-Version? Well, perhaps we should consider OpenStack-API-Version instead and drop the X-. Ref https://tools.ietf.org/html/rfc6648. 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
Re: [openstack-dev] [Ironic] weekly meetings and sub-team reports and people
On Thu, Jun 11, 2015 at 4:03 AM, Jim Rollenhagen j...@jimrollenhagen.com wrote: I'd really like to investigate moving this meeting to a different time. While it is beneficial for the sake of inclusivity, I tend to see not many cores attending (if at all), and usually not a ton of discussion. Well, anything in the range 2100UTC - 0700UTC would be nice for me :-) -- Michael Davies mich...@the-davies.net __ 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] how about those alternating meeting times?
On Tue, May 12, 2015 at 9:08 AM, Ruby Loo rlooya...@gmail.com wrote: Maybe the question is better posed to those folks -- was it useful or not? And if not, why? Because the date/time still didn't work, or because not enough (or the right persons) weren't there so their issues of interest weren't discussed, or they wouldn't have attended anyway, or ? And if it was useful, for how many was it useful? (Devananda's poll will capture some of that info.) I found it useful - it's nice to be awake at meeting time :) There's certainly a subset of the team that I never overlap with now, which is a shame, but timezones present challenges for a geographically dispersed team. Previously the meeting was at 4:30am (or 5:30am depending upon daylight savings), which was quite hard, but I did make it most weeks. The new timeslot of 2:30am/pm (3:30am/pm) is certainly only achievable for me every other week (no surprises for guessing which one :) I think it's great that we try and accommodate contributors from all around the globe! Michael... -- Michael Davies mich...@the-davies.net Rackspace Cloud Builders Australia __ 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] [Nova][Ironic] Large number of ironic driver bugs in nova
On Tue, May 12, 2015 at 8:58 AM, John Villalovos openstack@sodarock.com wrote: I work on Ironic and would be willing to be a cross project liaison for Nova and Ironic. I would just need a little info on what to do from the Nova side. Meetings to attend, web pages to monitor, etc... I assume I would start with this page: https://bugs.launchpad.net/nova/+bugs?field.tag=ironic And try to work with the Ironic and Nova teams on getting bugs resolved. I would appreciate any other info and suggestions to help improve the process. Just on this, I'll work with John so Nova has another person to bug in Ironicland :) -- Michael Davies mich...@the-davies.net Rackspace Cloud Builders Australia __ 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] How to deal with microversions in 3rdparty tools
On Tue, Apr 7, 2015 at 10:32 PM, Dmitry Tantsur dtant...@redhat.com wrote: I'm seeking for advice on what to do with microversions in discoverd. Basically I have the following options: 1. Do nothing. Get whatever behavior I can get from installed Ironic and Ironic client. Though unlikely, may get broken by future changes. 2. Demand version = 1.6. Looks like it keeps compatibility with old clients and servers, not sure what downsides are here. What are we going to recommend now as upstream? I agree with Jim R's suggestion - it's really up to the consumer as to what they want to do. Having said that... I think that any consumer wants to use the latest version of the API that it can support. And so since we're not planning on making any breaking API changes[1], I think any consumer wants to: a) have a concept of the latest API version that it has been coded for b) then, in negotiation with the server, choose a version that suffices: b1) negotiated_version = min(your code's max version, max Ironic server version) and b2) negotiated_version your code's supported version b3) negotiated_version Ironic API's minimum version I think that way you get the best of both worlds - stability, and latest functionality available. Jim R's suggestion of using latest is fine (especially for internal tools that can have a lower uptime) so long as you can deal quickly with any breakage should it occur :) [1] hopefully :) -- Michael Davies mich...@the-davies.net Rackspace Australia __ 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] thoughts on the midcycle
On Tue, Dec 30, 2014 at 9:15 AM, Devananda van der Veen devananda@gmail.com wrote: [snip] That being said, I'd also like to put forth this idea: if we had a second gathering (with the same focus on writing code) the following week (let's say, Feb 11 - 13) in the SF Bay area -- who would attend? Would we be able to get the other half of the core team together and get more work done? Is this a good idea? Just like to register my interest here - the time to get to SFO from AU is quite a bit less than Grenoble, so is something I would try to possibly make happen. -- Michael Davies mich...@the-davies.net Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Proposing new meeting times
On Tue, Nov 18, 2014 at 8:26 PM, Lucas Alvares Gomes lucasago...@gmail.com wrote: On Tue, Nov 18, 2014 at 1:00 AM, Devananda van der Veen devananda@gmail.com wrote: Option #1: alternate between Monday 1900 UTC Tuesday 0900 UTC. I like this because 1900 UTC spans all of US and western EU, while 0900 combines EU and EMEA. Folks in western EU are in the middle and can attend all meetings. http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=24hour=19min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=25hour=9min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 +1 +1 for Option 1. That's far more preferable for me :) -- Michael Davies mich...@the-davies.net Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] add cyclomatic complexity check to pep8 target
On Fri, Oct 17, 2014 at 2:39 PM, Joe Gordon joe.gord...@gmail.com wrote: First step in fixing this, put a cap on it: http://goog_106984861 https://review.openstack.org/129125 Thanks Joe - I've just put up a similar patch for Ironic: https://review.openstack.org/129132 -- Michael Davies mich...@the-davies.net Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Announcing Gertty 1.0.0: A console interface to Gerrit
On Fri, Sep 5, 2014 at 9:21 AM, Monty Taylor mord...@inaugust.com wrote: I, for one, welcome our new gertty overlords. As an early pre-release user who also sits on aeroplanes a lot, I have found gertty to be a MASSIVE productivity increase. I cannot possibly recommend it highly enough. Thank you for your work Jim! Agreed! Thank you Jim - I look forward to giving gertty a try. -- Michael Davies mich...@the-davies.net Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Designate Incubation Request
On Thu, May 29, 2014 at 4:22 AM, Sean Dague s...@dague.net wrote: I would agree this doesn't make sense in Neutron. I do wonder if it makes sense in the Network program. I'm getting suspicious of the programs for projects model if every new project incubating in seems to need a new program. Which isn't really a reflection on designate, but possibly on our program structure. I also agree here - DNS isn't a program by itself in my opinion, it should be in a group of other Network Application Services. -- Michael Davies mich...@the-davies.net Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] API weekly meeting
Yep, I'm interested! I'm in ACST (UTC+9:30) On 7 Mar 2014, at 11:15 am, Christopher Yeoh cbky...@gmail.com wrote: Hi, I'd like to start a weekly IRC meeting for those interested in discussing Nova API issues. I think it would be a useful forum for: - People to keep up with what work is going on the API and where its headed. - Cloud providers, SDK maintainers and users of the REST API to provide feedback about the API and what they want out of it. - Help coordinate the development work on the API (both v2 and v3) If you're interested in attending please respond and include what time zone you're in so we can work out the best time to meet. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] WSME / Pecan and only supporting JSON?
Hi everyone, Over in Ironic Land we're looking at removing XML support from ironic-api (i.e. https://bugs.launchpad.net/ironic/+bug/1271317) I've been looking, but I can't seem to find an easy way to modify the accepted content_types. Are there any wsgi / WSME / Pecan experts out there who can point me in the right direction? Thanks in advance, Michael... -- Michael Davies mich...@the-davies.net Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Future of the Nova API
On Tue, Feb 25, 2014 at 8:31 AM, Morgan Fainberg m...@metacloud.com wrote: On the topic of backwards incompatible changes: I strongly believe that breaking current clients that use the APIs directly is the worst option possible. All the arguments about needing to know which APIs work based upon which backend drivers are used are all valid, but making an API incompatible change when we've made the contract that the current API will be stable is a very bad approach. Breaking current clients isn't just breaking novaclient, it would also break any customers that are developing directly against the API. In the case of cloud deployments with real-world production loads on them (and custom development around the APIs) upgrading between major versions is already difficult to orchestrate (timing, approvals, etc), if we add in the need to re-work large swaths of code due to API changes, it will become even more onerous and perhaps drive deployers to forego the upgrades in lieu of stability. If the perception is that we don't have stable APIs (especially when we are ostensibly versioning them), driving adoption of OpenStack becomes significantly more difficult. Difficulty in driving further adoption would be a big negative to both the project and the community. TL;DR, don't break the contract. If we are seriously making incompatible changes (and we will be regardless of the direction) the only reasonable option is a new major version I'm absolutely in agreement here - thanks Morgan for raising this. Changing the API on consumers means forcing them to re-evaluate their options: Should I fix my usage of the API, or is it time to try another solution? The implementation cost is mostly the same. We can't assume that API breakages won't lead to customers leaving. It's worth noting that competing cloud APIs are inconsistent, and frankly awful. But they don't change because it's all about the commercial interest of retaining customers and supporting a cornucopia of SDKs. Any changes to a versioned API need to be completely backwards compatible, and we shouldn't assume changes aren't going to break things - we should test the crap out of them so as to ensure this is the case. Or put another way, any time we touch a stable API, we need to be extremely careful. If we want new features, if we want to clean up existing interfaces, it's far better to move to a new API version (even with the maintenance burden of supporting another API) than try and bolt something on the side. This includes improving input validation, because we should not be changing the functionality presented to end-users on a stable API, even if it's for their own good. What it comes down to is strongly supporting the consumers of our software. We need to make things easy for those who support and develop against the APIs. Hope this helps, Michael... -- Michael Davies mich...@the-davies.net Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Help a poor Nova Grizzy Backport Bug Fix
Hi all, I have a Nova Grizzly backport bug[1] in review[2] that has been hanging around for 4 months waiting for one more +2 from a stable team person. If there's someone kind enough to bump this through, it'd be appreciated ;) Thanks in advance, Michael... [1] https://launchpad.net/bugs/1188543 [2] https://review.openstack.org/#/c/54460/ -- Michael Davies mich...@the-davies.net Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Bad review patterns
On Fri, Nov 8, 2013 at 4:07 AM, Pedro Roque Marques pedro.r.marq...@gmail.com wrote: Radomir, An extra issue that i don't believe you've covered so far is about comment ownership. I've just read an email on the list that follows a pattern that i've heard many complaints about: -1 with a reasonable comment, submitter addresses the comment, reviewer never comes back. Reviewers do need to allocate time to come back and follow up on the answers to their comments. This is true, but it's not necessarily easy to find those reviews that you -1'd. I don't think anyone nefariously -1's and then goes away. Gerrit could be improved in this space to assist reviewers. -- Michael Davies mich...@the-davies.net Rackspace Cloud Builders Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] RFC: reverse the default Gerrit sort order
On Mon, Nov 11, 2013 at 3:06 PM, Monty Taylor mord...@inaugust.com wrote: [snip] - I have previously reviewed the patch is not a searchable term. (I know, because I'd like a view of things I have not reviewed yet) +1 FWIW, I'd like to see this too. Quickly finding reviews that I have or haven't already reviewed would improve productivity. -- Michael Davies mich...@the-davies.net Rackspace Cloud Builders Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][libvirt] Should file injection work for boot from volume images?
On Mon, Sep 23, 2013 at 6:20 PM, Thierry Carrez thie...@openstack.org wrote: Monty Taylor wrote: On 09/20/2013 02:47 PM, Michael Still wrote: Before https://review.openstack.org/#/c/46867/ if file injection of a mandatory file fails, nova just silently ignores the failure, which is clearly wrong. However, that review now can't land because its revealed another failure in the file injection code via tempest, which is... Should file injection work for instances which are boot from volume? Now that we actually notice injection failures we're now failing to boot such instances as file injection for them doesn't work. I'm undecided though -- should file injection work for boot from volume at all? Or should we just skip file injection for instances like this? I'd prefer to see us just support config drive and metadata server for these instances, but perhaps I am missing something really important. Well, first of all, I think file injection should DIAF everywhere. +1 That said, it may be no surprise that I think boot-from-volume should just do config drive and metadata. That sounds like the simplest way to preserve behavior. From what you said the current behavior is try, fail and ignore failure -- having noop instead is probably the right thing to do for havana. This behaviour is what is causing https://bugs.launchpad.net/nova/+bug/1188543 I've submitted a patch (https://review.openstack.org/#/c/48533/) that addresses the issue. It appears that: 1) File injection for instances which are boot from volume doesn't appear to have ever worked. 2) Attempting file injection just fails quietlyish and causes instance spawning slowdown 3) The code needed to do this properly isn't trivial and probably wouldn't land in Havana so late in the cycle. Instead of attempting file injection on a boot volume, my patch simply LOG.warns the user. I think that's the best solution for now. However I think we should address file injection in Icehouse as discussed in this thread. Thanks in advance, Michael... -- Michael Davies mich...@the-davies.net Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Code review study
On Tue, Aug 20, 2013 at 5:14 AM, Jay Buffington m...@jaybuff.com wrote: This is really interesting. I wish they would have explicitly defined lines of code. Is that git show |wc -l? Just the new lines which were added? The sum of the lines changed, removed and added? You can get vastly different numbers depending on how you count it. Normally in the literature LOC is defined as non-comment, non-blank code line deltas, with a few exceptions. The exceptions normally refer to not counting braces in C-style languages and other syntactic sugar elements. Of course in Python we don't really have these issues to content with :) I'd normally include comments and docstrings too, since we review these as well. Michael... -- Michael Davies mich...@the-davies.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
