[openstack-dev] [release][kolla] Announcing release of Kolla Mitaka rc3
Hey folks, We did a bangup job in the last 7 days fixing 25 bugs in Kolla. Our weekly capacity to solve bugs as a community is 25-30 bugs. Our final deadline is April 8th. Targeted for 2.0.0 (April 8tih) are currently 22 bugs. Many of these don't have owners, so if you want to contribute, please help by assigning yourself a bug and fixing it. https://launchpad.net/kolla/+milestone/2.0.0 Note we are following the standard OpenStack backport process for Newton bugs also in Mitaka, so please don't be concerned about backports, we will have the core reviewer team handling those unless there is a merge conflict. Regards -steve __ 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] Announcing release of Kolla Mitaka rc3
Hey folks, We did a bangup job in the last 7 days fixing 25 bugs in Kolla. Our weekly capacity to solve bugs as a community is 25-30 bugs. Our final deadline is April 8th. Targeted for 2.0.0 (April 8tih) are currently 22 bugs. Many of these don't have owners, so if you want to contribute, please help by assigning yourself a bug and fixing it. https://launchpad.net/kolla/+milestone/2.0.0 Note we are following the standard OpenStack backport process for Newton bugs also in Mitaka, so please don't be concerned about backports, we will have the core reviewer team handling those unless there is a merge conflict. Regards -steve __ 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] [TripleO] FreeIPA integration
I finally have enough understanding of what is going on with Tripleo to reasonably discuss how to implement solutions for some of the main security needs of a deployment. FreeIPA is an identity management solution that can provide support for: 1. TLS on all network communications: A. HTTPS for web services B. TLS for the message bus C. TLS for communication with the Database. 2. Identity for all Actors in the system: A. API services B. Message producers and consumers C. Database consumers D. Keystone service users 3. Secure DNS DNSSEC 4. Federation Support 5. SSH Access control to Hosts for both undercloud and overcloud 6. SUDO management 7. Single Sign On for Applications running in the overcloud. The main pieces of FreeIPA are 1. LDAP (the 389 Directory Server) 2. Kerberos 3. DNS (BIND) 4. Certificate Authority (CA) server (Dogtag) 5. WebUI/Web Service Management Interface (HTTPD) Of these, the CA is the most critical. Without a centralized CA, we have no reasonable way to do certificate management. Now, I know a lot of people have an allergic reaction to some, maybe all, of these technologies. They should not be required to be running in a development or testbed setup. But we need to make it possible to secure an end deployment, and FreeIPA was designed explicitly for these kinds of distributed applications. Here is what I would like to implement. Assuming that the Undercloud is installed on a physical machine, we want to treat the FreeIPA server as a managed service of the undercloud that is then consumed by the rest of the overcloud. Right now, there are conflicts for some ports (8080 used by both swift and Dogtag) that prevent a drop-in run of the server on the undercloud controller. Even if we could deconflict, there is a possible battle between Keystone and the FreeIPA server on the undercloud. So, while I would like to see the ability to run the FreeIPA server on the Undercloud machine eventuall, I think a more realistic deployment is to build a separate virtual machine, parallel to the overcloud controller, and install FreeIPA there. I've been able to modify Tripleo Quickstart to provision this VM. I was also able to run FreeIPA in a container on the undercloud machine, but this is, I think, not how we want to migrate to a container based strategy. It should be more deliberate. While the ideal setup would be to install the IPA layer first, and create service users in there, this produces a different install path between with-FreeIPA and without-FreeIPA. Thus, I suspect the right approach is to run the overcloud deploy, then "harden" the deployment with the FreeIPA steps. The IdM team did just this last summer in preparing for the Tokyo summit, using Ansible and Packstack. The Rippowam project https://github.com/admiyo/rippowam was able to fully lock down a Packstack based install. I'd like to reuse as much of Rippowam as possible, but called from Heat Templates as part of an overcloud deploy. I do not really want to re implement Rippowam in Puppet. So, big question: is Heat->ansible (instead of Puppet) for an overcloud deployment an acceptable path? We are talking Ansible 1.0 Playbooks, which should be relatively straightforward ports to 2.0 when the time comes. Thus, the sequence would be: 1. Run existing overcloud deploy steps. 2. Install IPA server on the allocated VM 3. Register the compute nodes and the controller as IPA clients 4. Convert service users over to LDAP backed services, complete with necessary kerberos steps to do password-less authentication. 5. Register all web services with IPA and allocate X509 certificates for HTTPS. 6. Set up Host based access control (HBAC) rules for SSH access to overcloud machines. When we did the Rippowam demo, we used the Proton driver and Kerberos for securing the message broker. Since Rabbit seems to be the tool of choice, we would use X509 authentication and TLS for encryption. ACLs, for now, would stay in the flat file format. In the future, we might chose to use the LDAP backed ACLs for Rabbit, as they seem far more flexible. Rabbit does not currently support Kerberos for either authentication or encryption, but we can engage the upstream team to implement it if desired in the future, or we can shift to a Proton based deployment if Kerberos is essential for a deployment. There are a couple ongoing efforts that will tie in with this: 1. Designate should be able to use the DNS from FreeIPA. That was the original implementation. 2. Juan Antonio Osorio has been working on TLS everywhere. The issue thus far has been Certificate management. This provides a Dogtag server for Certs. 3. Rob Crittenden has been working on auto-registration of virtual machines with an Identity Provider upon launch. This gives that efforts an IdM to use. 4. Keystone can make use of the Identity store for administrative users in their own domain. 5.
Re: [openstack-dev] [tc][kolla] Change to kolla's release model to gain access to release's website marketing
On 4/2/16, 1:08 PM, "Doug Hellmann" wrote: > >> On Apr 2, 2016, at 1:20 PM, Steven Dake (stdake) >>wrote: >> >> A big correction to this thread below. >> >> On 4/2/16, 10:05 AM, "Steven Dake (stdake)" wrote: >> >>> >>> >>> On 4/2/16, 10:01 AM, "Jeremy Stanley" wrote: >>> On 2016-04-02 16:13:28 + (+), Steven Dake (stdake) wrote: [...] > I feel as though we are not permitted to participate in the > marketing that takes place on the releases website [...] I'll refrain from commenting on the rest since I'm not a member of the release team, but I *seriously* hope we've not created a "marketing" portal simply by way of tracking version numbers, changelogs and release schedules. I have a feeling few (if any) of the release team wants to get into the marketing business and I'm happy to help do whatever is in my power to neuter the "marketing potential" for releases.openstack.org so it can be viewed simply as a source of _objective_ technical data. -- >>> >>> It is objective technical data, but atm we are excluded, and people >>>look >>> at that objective technical data (like marketing and sales folks) to >>>make >>> decisions, so it is by its very nature a marketing resource as well. >>>If >>> we are excluded, sales and marketing folks that make decisions about >>> OpenStack deployments may come along and say "not on the website, not >>> legitimate". >> >> release:independent projects are rendered on this website [1], and ttx's >> review comment was more to put kolla in releases:independent of the >> releases repo rather then the mitaka location [1]. I misunderstood >>ttx's >> comments to mean we were completely excluded which is not the case. > >Right, we just need it filed under the right directory. Note I submitted a change [1] to clarify this - since it wasn't documented. But I'm glad dims was able to reach out to me on irc to clarify the situation. Thanks dims! > >> >> That said, release:cycle-with-milestones is still what we want :) > >The model change can be approved and applied to Newton. During Newton >we¹ll figure out how to communicate about projects that have changed >their tags ‹ we don¹t want to rewrite history for old releases but we >don¹t want it to be hard for users to find full project history. I have >some ideas to handle it but I¹m waiting until after the summit to >implement them. Sounds good. I understand now is not the optimal time to request such changes to how the releases repository works. I hope the outcome is that projects that were really following release:cycle-with* have an opportunity to be marked in the appropriate place even if it does mean rewriting history, since our intent with our big tent application wasn't for our projects to be marked as "independent" on the releases website. I believe the intent of the project is what matters most and we clearly followed the release cycle pretty closely in Liberty and Mitaka (with the exception of a dental medical emergency which almost killed me :(which made our tagging late for one milestone). At the time of our big tent application there was no releases website, or we would have definitely chosen release-with-intermeditary. Unfortunately that warning wasn¹t there at the time and we can't fix the past, so Newton it is :) You can see from my PTL candidacy for Mitaka [2] that I was keen to have the release:managed tag back then, and that applies even more so now. Regards, -steve [1] https://review.openstack.org/300823 [2] https://github.com/openstack/election/blob/master/candidates/mitaka/Kolla/S teven_Dake.txt#L35 Regards -steve > >Doug > >> >> I'd ask people cut me a little slack on this, I am new to the >> openstack/releases repository ;) >> >> [1] http://releases.openstack.org/independent.html >> [2] https://review.openstack.org/#/c/297976/ >>> >>> Regards >>> -steve >>> 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 >>> >>> >>> >>> >>>__ >>> 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 Devel
Re: [openstack-dev] Acknowledging Jim Blair's work on the TC
> On Apr 1, 2016, at 3:06 PM, Anita Kuno wrote: > > Jim is an incumbent on the TC this election and he didn't run. I'm > posting this to express my thanks to Jim for his work and dedication on > the TC. > > Jim, I think your commitment to open source, spanning many years before > OpenStack, and your dedication to governance process, are qualities I > admire very much and I'm grateful you were able to voice your opinions > on the TC from October 2013 until now. > > Thank you for taking your turn and thank you as well for allowing others > a chance to take theirs. > > Thank you, Jim, > Anita. Nicely put. I also appreciate that Jim’s perspective is often different from my own initial reaction to a situation. As a result, I’ve learned a lot by serving on the TC with him. Thanks, Jim! Doug __ 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] [tc][kolla] Change to kolla's release model to gain access to release's website marketing
> On Apr 2, 2016, at 1:20 PM, Steven Dake (stdake) wrote: > > A big correction to this thread below. > > On 4/2/16, 10:05 AM, "Steven Dake (stdake)" wrote: > >> >> >> On 4/2/16, 10:01 AM, "Jeremy Stanley" wrote: >> >>> On 2016-04-02 16:13:28 + (+), Steven Dake (stdake) wrote: >>> [...] I feel as though we are not permitted to participate in the marketing that takes place on the releases website >>> [...] >>> >>> I'll refrain from commenting on the rest since I'm not a member of >>> the release team, but I *seriously* hope we've not created a >>> "marketing" portal simply by way of tracking version numbers, >>> changelogs and release schedules. I have a feeling few (if any) of >>> the release team wants to get into the marketing business and I'm >>> happy to help do whatever is in my power to neuter the "marketing >>> potential" for releases.openstack.org so it can be viewed simply as >>> a source of _objective_ technical data. >>> -- >> >> It is objective technical data, but atm we are excluded, and people look >> at that objective technical data (like marketing and sales folks) to make >> decisions, so it is by its very nature a marketing resource as well. If >> we are excluded, sales and marketing folks that make decisions about >> OpenStack deployments may come along and say "not on the website, not >> legitimate". > > release:independent projects are rendered on this website [1], and ttx's > review comment was more to put kolla in releases:independent of the > releases repo rather then the mitaka location [1]. I misunderstood ttx's > comments to mean we were completely excluded which is not the case. Right, we just need it filed under the right directory. > > That said, release:cycle-with-milestones is still what we want :) The model change can be approved and applied to Newton. During Newton we’ll figure out how to communicate about projects that have changed their tags — we don’t want to rewrite history for old releases but we don’t want it to be hard for users to find full project history. I have some ideas to handle it but I’m waiting until after the summit to implement them. Doug > > I'd ask people cut me a little slack on this, I am new to the > openstack/releases repository ;) > > [1] http://releases.openstack.org/independent.html > [2] https://review.openstack.org/#/c/297976/ >> >> Regards >> -steve >> >>> >>> 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 >> >> >> __ >> 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] [tc][kolla] Change to kolla's release model to gain access to release's website marketing
> On Apr 2, 2016, at 1:01 PM, Jeremy Stanley wrote: > > On 2016-04-02 16:13:28 + (+), Steven Dake (stdake) wrote: > [...] >> I feel as though we are not permitted to participate in the >> marketing that takes place on the releases website > [...] > > I'll refrain from commenting on the rest since I'm not a member of > the release team, but I *seriously* hope we've not created a > "marketing" portal simply by way of tracking version numbers, > changelogs and release schedules. I have a feeling few (if any) of > the release team wants to get into the marketing business and I'm > happy to help do whatever is in my power to neuter the "marketing > potential" for releases.openstack.org so it can be viewed simply as > a source of _objective_ technical data. That’s the idea, though there will be some inevitable marketing side-effects. We have been trying to be strict with having projects declare their release tags early in the cycle [1] so that we can point to the releases site as clearly communicating a team’s intent so that users know what to expect. This was the first cycle where there were any real ramifications to choosing the “wrong” release model, and we’ve had discussions with a few teams throughout the cycle and more recently I proposed a warning to the documentation for the independent model tag specifically about that [2]. The situation is similar to the projects we’ve had that didn’t actually build a release artifact. Since we can’t point to a release, it’s not clear to end users that they *did* release. Anyway, this is all relatively new, so we expected some issues. We’re dealing with them on a case-by-case basis, trying to be flexible but at the same time trying to ensure we’re not watering down any of the declarations and all with the understanding that if a team is unhappy with the outcome for Mitaka it can be fixed for Newton (hint: teams that want to change their release model for Newton should submit the governance patch to do that now). Doug [1] http://lists.openstack.org/pipermail/openstack-dev/2016-January/083726.html [2] https://review.openstack.org/#/c/299309/ __ 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] [tc][kolla] Change to kolla's release model to gain access to release's website marketing
A big correction to this thread below. On 4/2/16, 10:05 AM, "Steven Dake (stdake)" wrote: > > >On 4/2/16, 10:01 AM, "Jeremy Stanley" wrote: > >>On 2016-04-02 16:13:28 + (+), Steven Dake (stdake) wrote: >>[...] >>> I feel as though we are not permitted to participate in the >>> marketing that takes place on the releases website >>[...] >> >>I'll refrain from commenting on the rest since I'm not a member of >>the release team, but I *seriously* hope we've not created a >>"marketing" portal simply by way of tracking version numbers, >>changelogs and release schedules. I have a feeling few (if any) of >>the release team wants to get into the marketing business and I'm >>happy to help do whatever is in my power to neuter the "marketing >>potential" for releases.openstack.org so it can be viewed simply as >>a source of _objective_ technical data. >>-- > >It is objective technical data, but atm we are excluded, and people look >at that objective technical data (like marketing and sales folks) to make >decisions, so it is by its very nature a marketing resource as well. If >we are excluded, sales and marketing folks that make decisions about >OpenStack deployments may come along and say "not on the website, not >legitimate". release:independent projects are rendered on this website [1], and ttx's review comment was more to put kolla in releases:independent of the releases repo rather then the mitaka location [1]. I misunderstood ttx's comments to mean we were completely excluded which is not the case. That said, release:cycle-with-milestones is still what we want :) I'd ask people cut me a little slack on this, I am new to the openstack/releases repository ;) [1] http://releases.openstack.org/independent.html [2] https://review.openstack.org/#/c/297976/ > >Regards >-steve > >> >>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 > > >__ >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] [tc][kolla] Change to kolla's release model to gain access to release's website marketing
On 4/2/16, 10:01 AM, "Jeremy Stanley" wrote: >On 2016-04-02 16:13:28 + (+), Steven Dake (stdake) wrote: >[...] >> I feel as though we are not permitted to participate in the >> marketing that takes place on the releases website >[...] > >I'll refrain from commenting on the rest since I'm not a member of >the release team, but I *seriously* hope we've not created a >"marketing" portal simply by way of tracking version numbers, >changelogs and release schedules. I have a feeling few (if any) of >the release team wants to get into the marketing business and I'm >happy to help do whatever is in my power to neuter the "marketing >potential" for releases.openstack.org so it can be viewed simply as >a source of _objective_ technical data. >-- It is objective technical data, but atm we are excluded, and people look at that objective technical data (like marketing and sales folks) to make decisions, so it is by its very nature a marketing resource as well. If we are excluded, sales and marketing folks that make decisions about OpenStack deployments may come along and say "not on the website, not legitimate". Regards -steve > >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 __ 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] [tc][kolla] Change to kolla's release model to gain access to release's website marketing
On 2016-04-02 16:13:28 + (+), Steven Dake (stdake) wrote: [...] > I feel as though we are not permitted to participate in the > marketing that takes place on the releases website [...] I'll refrain from commenting on the rest since I'm not a member of the release team, but I *seriously* hope we've not created a "marketing" portal simply by way of tracking version numbers, changelogs and release schedules. I have a feeling few (if any) of the release team wants to get into the marketing business and I'm happy to help do whatever is in my power to neuter the "marketing potential" for releases.openstack.org so it can be viewed simply as a source of _objective_ technical data. -- 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
[openstack-dev] [tc][kolla] Change to kolla's release model to gain access to release's website marketing
Technical Committee, Please accept my change prior to our April 8th deadline for tagging Mitaka 2.0.0 of Kolla. To be clear, this is a clunky workaround but I feel as though we are not permitted to participate in the marketing that takes place on the releases website, and this is the lesser of that evil. The review is here: https://review.openstack.org/300752 I'd like to do it right, and remove the red tape surrounding deployment projects first, but from what I've gathered on the mailing list (sorry no references) and in various reviews I've been involved with, solving the red tape related to deployment projects won't happen in time to apply this tag to our repository as this tag operates on a 7 day lazy consensus model, which means Kolla can still possibly gain access to the marketing resources of the releases project team's website. Regards -steve __ 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] 答复: [Heat] Re-evaluate conditions specification
> parameters: > env: >type: string >default: prod > > is_prod: > type: boolean > default: {equals: {get_param, env}} > > From an interface standpoint this seems much cleaner and more intuitive than > the other solutions discussed IMHO, but I suspect it's potentially harder to > implement. > > Your original example gets much cleaner too if we allow all intrinsic function > (except get_attr) in the scope of parameters: > > parameters: > host: > type: string > port: > type: string > endpoint: > type: string > default: > str_replace: > template: >http://HOSTORT/ > params: >HOST: {get_param: host} >PORT: {get_param: port} > > Steve +1 to restricting the variable evaluation into the 'parameters' section which we can treat as the 'static' part of a template. Maybe that is one of the reasons why aws has a 'conditions' section to avoid getting into the lazy evaluation mess? Regards, Qiming __ 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] [ptl] [security][tc] Tidy up language in section 5 of the vulnerability:managed tag
Apologies for not copying the [ptl] tag, since this change affects mostly the PTLs and the projects for which they facilitate. Note PTL's the purpose of this change is to make your lives easier and streamline the VMT application process, but keep the spirit of the original requirement in place. Given that this change is to help make he lives of the PTL and security team easier, if both could weigh in ion the review, I'd appreciate it. I'd like to get the language correct so we don't have to keep changing section 5 of this tag or special case it to death since that is an anti-pattern in the governance repository. If PTLs, project partiicipants, or anyone else for that matter have any wording changes, feel free to propose them - IANAL and writing these things correctly is hard to do properly ); involving the community around the pain points of the tagging process is what I'm after. Regards -steve From: Steven Dake mailto:std...@cisco.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Friday, April 1, 2016 at 5:04 PM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [security][tc] Tidy up language in section 5 of the vulnerability:managed tag Please see my review here as requested in this thread [1]: https://review.openstack.org/300698 The purpose of this review is two fold: 1. Permit sponsoring companies of single vendor projects or projects with low company affiliation diversity to allow their own security experts to sign off on a threat analysis, acting as a third party.. 2. Enable scaling of the OSSA and VMT processes by permitting projects to self-audit, self-review, or self-threat analyze with the condition that an impartial third party take responsibility for approving the audit, review, or threat analysis. [1] http://lists.openstack.org/pipermail/openstack-dev/2016-March/091075.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
Re: [openstack-dev] [magnum] Proposing Eli Qiao for Magnum core reviewer team
+ 1 for Eli :) Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan) IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Hongbin Lu To: "OpenStack Development Mailing List (not for usage questions)" Date: 01/04/2016 02:20 am Subject:[openstack-dev] [magnum] Proposing Eli Qiao for Magnum core reviewer team Hi all, Eli Qiao has been consistently contributed to Magnum for a while. His contribution started from about 10 months ago. Along the way, he implemented several important blueprints and fixed a lot of bugs. His contribution covers various aspects (i.e. APIs, conductor, unit/functional tests, all the COE templates, etc.), which shows that he has a good understanding of almost every pieces of the system. The feature set he contributed to is proven to be beneficial to the project. For example, the gate testing framework he heavily contributed to is what we rely on every days. His code reviews are also consistent and useful. I am happy to propose Eli Qiao to be a core reviewer of Magnum team. According to the OpenStack Governance process [1], we require a minimum of 4 +1 votes within a 1 week voting window (consider this proposal as a +1 vote from me). A vote of -1 is a veto. If we cannot get enough votes or there is a veto vote prior to the end of the voting window, Eli is not able to join the core team and needs to wait 30 days to reapply. The voting is open until Thursday April 7st. [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess Best regards, Hongbin __ 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] Acknowledging Jim Blair's work on the TC
On Fri, Apr 1, 2016 at 12:06 PM, Anita Kuno wrote: > Jim is an incumbent on the TC this election and he didn't run. I'm > posting this to express my thanks to Jim for his work and dedication on > the TC. > > Jim, I think your commitment to open source, spanning many years before > OpenStack, and your dedication to governance process, are qualities I > admire very much and I'm grateful you were able to voice your opinions > on the TC from October 2013 until now. > > Thank you for taking your turn and thank you as well for allowing others > a chance to take theirs. > > Thank you, Jim, > Anita. > > > Well said and 100% agree! Thank you Jim! __ 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][python-neutronclient] Adding new options to the existing Neutron CLIs
2016-03-18 12:06 GMT+09:00 reedip banerjee : > Dear All Neutron Developers and Reviewers, > > I have a query/concern related to the parsing of options in > python-neutronclient. > I would like to bring this up, as it "may" also impact the transition of the > CLIs to the openstack client as well. > > NeutronClient is pretty special in its behavior, and has one pretty powerful > feature of parsing extra options. This feature states that, if the CLI does > not support an option but the API does, and the user passes a value for this > option, then the "unsupported" CLI option is parsed , and forwarded to the > Neutron Server for processing. > > Example: > Currently "neutron net-create" does not support --router:external. If you > see the output of "neutron net-create -h" you would not find > "--router-external". However, this option is supported in the API since Juno > [2]. So therefore , if a user executes the following CLI > " neutron net-create TestNetwork --router-external" > > then [1] would be observed as an output. We can use "--router:external" since the initial support of neutron router (Folsom). You are talking about the situation that it is not described in the help message. It is better to have it in the help message. > Now the query/concern comes next > Any option which is not supported by the CLI is open to the above parsing. > Therefore , for net-create and net-update, all the following are possible: > > neutron net-create --router:external=True TESTNetwork --(A) > neutron net-create --router:external TESTNetwork --(B) > neutron net-create TESTNetwork --router:external --(C) > neutron net-create TESTNetwork --router:external=True --(D) > neutron net-create TESTNetwork --router:external True --(E) > > However, user is not aware of the --router:external option because it is not > visible in the HELP section ( this is true for other CLI options as well). > > In order to demonstrate these options to the User, we have to update > add_known_arguments function to display them. And once they are known to the > CLI, the parsing changes, and some of the options from (A) to (E) may not be > supported ( Please see [3] for an ongoing, though now dormant, discussion ). > > Note that this discussion is not limited only to net-create, but possibly > other CLIs as well which do not completely expose the Options which the API > can support.I am , however, taking the net-create example as a case-study. > > I would like to know how we can move forward in this regards: > > -- Should NeutronClient continue to support all options from (A) to (E), but > deprecate some of them in Openstack Client? As Richard said, we don't plan to support the extra arguments in openstackclient, so this is not a problem in the openstackclient migration. In OpenStack Client, we should follow OpenStack client option convention. I don't think it is a DEPRECATION of some options. It is a DERECATION of neutronclient CLI itself. > -- Should we deprecate them in NeutronClient itself, so that the users are > comfortable with the options when the migration to Openstack Client occurs? My vote is to keep the current behavior. On the other hand I don't think we need to show all available patterns. Akihiro > > -- Any other suggestions > > [1]: http://paste.openstack.org/show/491032/ > > [2]: > http://docs.openstack.org/juno/install-guide/install/apt/content/neutron_initial-external-network.html > > [3]: https://review.openstack.org/#/c/137279/ > > -- > Thanks and Regards, > Reedip Banerjee > IRC: reedip > > > > > > __ > 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] [bifrost][ironic][release] missing build artifacts
Excerpts from Julia Kreger's message of 2016-04-01 18:21:24 -0400: > On Fri, Apr 1, 2016 at 4:48 PM, Doug Hellmann wrote: > > > Excerpts from Doug Hellmann's message of 2016-04-01 16:25:07 -0400: > > > Ironic/Bifrost team, > > > > > > > > > It would be good to understand what your intent is for builds. Can > > > you follow up here on this thread with some details? > > > > > > > First time partial user of the deliverables release tagging and didn't > realize that we were > missing the configuration necessary to push a tag up to tarballs.o.o. Would > landing > 300646 and then reverting it after 300474 has landed result in the > artifacts being built > and pushed to tarballs.o.o? The tarball job is triggered when a new tag is added, so no. Now that the correct jobs are in place you could apply a new tag to produce an artifact, though. If you re-tag the same SHA as 1.0.0 with version 1.0.1, we will at least have that. We can decide what to do about the missing artifacts separately (either remove them from the record or disable the links to those versions). You can either tag directly and then record the results in the releases repo, or you can submit a release request and let the release team process it. Doug > > > > > I forgot to mention that https://review.openstack.org/#/c/300474 > > includes some changes to add the simple server publishing jobs. If you > > want to use those, please +1 the patch. __ 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] [monasca][release] missing build artifacts
Excerpts from Hochmuth, Roland M's message of 2016-04-02 01:35:35 +: > Hi Doug, You had mentioned issues with three repos: > > 1. monasca-ceilometer > 2. monasca-log-api > 3. monasca-thresh > > All the repos that have Python code I believe are in reasonable shape with > respect to the Python deliverables except for the following two repos: > > 1. monasca-ceilometer > 2. monasca-log-api > > I'm not sure we should attempt to resolve these two repos for the Mitaka > release, but we can try. It might be too late. They aren't in heavy usage and > are relatively new. I think for those you were missing the "venv" environment in tox.ini that the jobs use to run arbitrary commands. Have a look at some of the other repos for an example of how to set that up, or ask the infra team (I'm not sure where it's documented, unfortunately, or I would direct you there). > > > monasca-thresh is a pure Java component. > > In the process of looking at monasca-thresh it looks like there is a general > issue with all the Java deliverables. All the Java jars are built and > uploaded in their respective folders such as, > http://tarballs.openstack.org/ci/monasca-thresh/. Note the "ci". However, we > don't move the jars that are in this directory up a level to > http://tarballs.openstack.org/monasca-thresh/. It looks like that needs to > get resolved. > > > A proposal that I think would resolve this is as follows: > > 1. Update versions of Java jars in the pom.xml for each project to something > like 2.0 on the stable/mitaka branch. This will result in a new jar file > being created with a nice version and name. Note, this step isn't necessary, > but if we did this we would have a nice version for Mitaka. If the artifacts exist but are in the "wrong" place, maybe someone from the infra team can copy them into place for you. Then if you give us an example of what the filenames are, the release team can update the tools in the releases repo to generate links to them (I assume, for example, they are not .tar.gz files). > 2. Figure out how to copy the jars over to their respective folders in > http://tarballs.openstak.org. For Python I think the script that does this is > publish-to-pypi, but for Java code, not sure exactly what needs to be done. Yes, you need to work with infra to set up the necessary build scripts. It's probably not realistic to do this in the next week, but if you get the existing files copied into place then you can work on updating the job before the Newton-1 milestone tagging deadline. Doug > > I think the two steps above would get us in compliance again for > monasca-thresh and all the Java code in the other repos. > > Does that seem like a reasonable plan at this point? > > Regards --Roland > > On 4/1/16, 2:36 PM, "Doug Hellmann" wrote: > > >Excerpts from Hochmuth, Roland M's message of 2016-04-01 20:06:28 +: > >> Hi Doug, Sorry, this is our first release and we want to do the right > >> thing. > >> > >> monasca-ceilometer is the code that plugs into the Ceilometer publisher > >> and Ceilometer storage driver to allow Ceilometer to send metrics to the > >> Monasca API and use Monasca as a storage backend. We don't create a pypi > >> for this component. > > > >How do you users receive that code and install it? We at least need > >a tarball built. If you don't want to publish to pypi, you can use > >the job definitions that the Python server projects use to build > >artifacts. > > > >> monasca-log-api is probably not set up completely, but it should be > >> similar to the monasca-api. > >> > >> monasca-thresh remains purely Java code. There is a build, but it isn't a > >> Python build so there isn't a tox.ini. Not sure how to deliver this, but > >> the current java build overwrites the jar each time it builds so it sounds > >> like that would need to be fixed. > > > >Are those JAR files going somewhere we could link to? > > > >> > >> I guess, judging by the issues, I don't quite understand what > >> "deliverables" are. I was thinking it was the tagged code, but obviously > >> it includes the build too. It sounds like we have more work ahead of us. > > > >Most of our distributors want a tarball or sdist or other artifact they > >can use to build a package from. For the Python-based apps, we have > >templates you can use in the zuul/layout.yaml file to introduce those > >jobs into the right zuul queues. The release or infra teams can help you > >identify the right template to use. > > > >> Let me know how you want to proceed. > > > >We only want to be linking to things we're actually publishing. The > >first patch I mentioned removes the links so the Monasca projects > >that don't have builds. The second patch removes the projects > >entirely, but if we can update the page to link to a downloadable > >artifact (rather than just a git repo tag) then we can keep the > >projects in the list. We can get downloadable artifacts by having > >you add build jobs and t
Re: [openstack-dev] [congress][release] missing build artifacts
Excerpts from Tim Hinrichs's message of 2016-04-01 22:46:59 +: > Hi Doug, > > Thanks for letting us know. Here's what we're intending... > - We'd like to release the server code for Mitaka. > - We release the client to Pypi, so that's already taken care of. > - We haven't moved our docs off of readthedocs yet, so we're taking care of > that as well. > > I gave a +1 to your patch for adding openstack-server-release-jobs to zuul. > I also pushed a congress-only patch for the same, thinking that's probably > what you actually wanted us to do. > https://review.openstack.org/#/c/300682/ Now that the jobs are in place, we should tag new release candidates using new versions and the same SHAs as the last candidate to get the artifacts built properly. You can submit the request for that using the releases repo, or you can tag yourself and submit the info after the fact. We will decide what to do about the old artifacts you have on launchpad separately. > > I gave a -1 to your patch that removes all the Congress deliverables from > openstack/releases, thinking that we can have this sorted out quickly. The > job we're missing just produces a tarball and uploads it, right? We've > been manually doing releases up to this point, which is why we didn't have > the job in place. > https://review.openstack.org/300644 > > I didn't touch your change on the artifact-link-mode, since it seems like a > short-term solution that may go in before we get everything sorted. > https://review.openstack.org/300457 Yes, we'll merge that as a short-term fix until we have the rest of it worked out. Doug > > Tim > > On Fri, Apr 1, 2016 at 1:23 PM Doug Hellmann wrote: > > > Congress team, > > > > We noticed in our audit of the links on > > http://releases.openstack.org/mitaka/index.html that the links to > > the build artifacts for congress point to missing files. The > > repository doesn't seem to have any real build jobs configured in > > openstack-infra/project-config/zuul/layout.yaml, so it's not clear > > how tagging is producing a release for you. > > > > For now, we are disabling links to the artifacts for those repos > > via https://review.openstack.org/300457 but we're also planning to > > remove them from the official Mitaka page since there don't > > appear to be any actual related deliverables > > (https://review.openstack.org/300644). > > > > It would be good to understand what your intent is for builds. Can > > you follow up here on this thread with some details? > > > > Thanks, > > Doug > > > > __ > > 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] [magnum] Split k8s-client in separate python package
Hongbin, Here's what i came up with based on your feedback: https://review.openstack.org/#/c/300729/ Thanks, Dims On Fri, Apr 1, 2016 at 6:19 PM, Hongbin Lu wrote: > Dims, > > Thanks for splitting the k8sclient code out. Below is my answer to your > question. > > - Should this be a new openstack/ repo? > Yes, I think so. We need it in openstack namespace in order to leverage the > openstack infra for testing and packaging. > > - Would the Magnum team own the repo and use the new python package? > If this library is mainly used by Magnum, I think Magnum team has no problem > to own it. If it is also used by other projects, I am afraid Magnum team > won't have enough bandwidth to support it. In such case, it is better to have > other teams to share the ownership. > > Best regards, > Hongbin > > -Original Message- > From: Davanum Srinivas [mailto:dava...@gmail.com] > Sent: April-01-16 3:36 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [magnum] Split k8s-client in separate python package > > Team, > > I've been meaning to do this for a while. Short version, see repo: > https://github.com/dims/python-k8sclient/ > > Long version: > - Started from the magnum repo. > - pulled out just ./magnum/common/pythonk8sclient > - preserved entire history in case we had to go back > - reorganized directory structure > - ran openstack cookie cutter and added generated files > - added a test that actually works against a live k8s :) > > https://github.com/dims/python-k8sclient/blob/master/k8sclient/tests/test_k8sclient.py > > Question: > - Should this be a new openstack/ repo? > - Would the Magnum team own the repo and use the new python package? > > Thanks, > Dims > > > -- > Davanum Srinivas :: https://twitter.com/dims > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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