Re: [openstack-dev] [requirements][daisycloud][freezer][fuel][solum][tatu][trove] pycrypto is dead and insecure, you should migrate part 2
These project seem dies. On Mon, Jun 11, 2018 at 5:48 AM, Matthew Thode wrote: > On 18-06-04 14:06:24, Matthew Thode wrote: > > On 18-05-13 12:22:06, Matthew Thode wrote: > > > This is a reminder to the projects called out that they are using old, > > > unmaintained and probably insecure libraries (it's been dead since > > > 2014). Please migrate off to use the cryptography library. We'd like > > > to drop pycrypto from requirements for rocky. > > > > > > See also, the bug, which has most of you cc'd already. > > > > > > https://bugs.launchpad.net/openstack-requirements/+bug/1749574 > > > > > > > ++-- > ---+--+- > --+ > > | Repository | Filename > | Line | Text > | > > ++-- > ---+--+- > --+ > > | daisycloud-core| code/daisy/requirements.txt >| 17 | pycrypto>=2.6 # Public > Domain | > > | freezer| requirements.txt > | 21 | pycrypto>=2.6 # Public > Domain | > > | fuel-dev-tools | > > contrib/fuel-setup/requirements.txt >|5 | pycrypto==2.6.1 >| > > | fuel-web | nailgun/requirements.txt > | 24 | pycrypto>=2.6.1 > | > > | solum | requirements.txt > | 24 | pycrypto # Public Domain > | > > | tatu | requirements.txt > |7 | pycrypto>=2.6.1 > | > > | tatu | test-requirements.txt >|7 | pycrypto>=2.6.1 >| > > | trove | integration/scripts/files/ > requirements/fedora-requirements.txt | 30 | pycrypto>=2.6 # > Public Domain| > > | trove | integration/scripts/files/ > requirements/ubuntu-requirements.txt | 29 | pycrypto>=2.6 # > Public Domain| > > | trove | requirements.txt > | 47 | pycrypto>=2.6 # Public > Domain | > > ++-- > ---+--+- > --+ > > > > In order by name, notes follow. > > > > daisycloud-core - looks like AES / random functions are used > > freezer - looks like AES / random functions are used > > solum - looks like AES / RSA functions are used > > trove - has a review!!! https://review.openstack.org/# > /c/560292/ > > > > The following projects are not tracked so we won't wait on them. > > fuel-dev-tools, fuel-web, tatu > > > > so it looks like progress is being made, so we have that going for us, > > which is nice. What can I do to help move this forward? > > > > It does not look like the projects (other than trove) are moving forward > on this. > > -- > Matthew Thode (prometheanfire) > > __ > 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 > > -- Shake 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
Re: [openstack-dev] [kolla] Ubuntu jobs failed on pike branch due to package dependency
I prefer to the option 2. On Mon, Feb 26, 2018 at 4:39 PM, Jeffrey Zhang wrote: > Recently, the Ubuntu jobs on pike branch are red[0]. With some debugging, > i found it is caused by > package dependency. > > > *Background* > > Since we have no time to upgrade ceph from Jewel to Luminous at the end of > pike cycle, we pinned > Ceph to Jewel on pike branch. This works on CentOS, because ceph jewel and > ceph luminous are on > the different repos. > > But in Ubuntu Cloud Archive repo, it bump ceph to Luminous. Even though > ceph luminous still exists > on UCA. But since qemu 2.10 depends on ceph luminous, we have to ping qemu > to 2.5 to use ceph Jewel[1]. > And this works since then. > > > *Now Issue* > > But recently, UCA changed the libvirt-daemon package dependency, and added > following, > > Package: libvirt-daemon > Version: 3.6.0-1ubuntu6.2~cloud0 > ... > Breaks: qemu (<< 1:2.10+dfsg-0ubuntu3.4~), qemu-kvm (<< > 1:2.10+dfsg-0ubuntu3.4~) > > It requires qemu 2.10 now. So dependency is broken and nova-libvirt > container is failed to build. > > > *Possible Solution* > > I think there two possible ways now, but none of them is good. > > 1. install ceph Luminuous on nova-libvirt container and ceph Jewel in > ceph-* container > 2. Bump ceph from jewel to luminous. But this breaks the backport policy, > obviously. > > So any idea on this? > > [0] https://review.openstack.org/534149 > [1] https://review.openstack.org/#/c/526931/ > > -- > Regards, > Jeffrey Zhang > Blog: http://xcodest.me > > __ > 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 > > -- Shake 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
Re: [openstack-dev] [Openstack-operators] [tripleo] Making containerized service deployment the default
I think tripleo use kolla and kolla-ansible would be perfect. On Tue, Sep 19, 2017 at 3:47 AM, Mohammed Naser wrote: > On Mon, Sep 18, 2017 at 3:04 PM, Alex Schultz wrote: > > Hey ops & devs, > > > > We talked about containers extensively at the PTG and one of the items > > that needs to be addressed is that currently we still deploy the > > services as bare metal services via puppet. For Queens we would like > > to switch the default to be containerized services. With this switch > > we would also start the deprecation process for deploying services as > > bare metal services via puppet. We still execute the puppet > > configuration as part of the container configuration process so the > > code will continue to be leveraged but we would be investing more in > > the continual CI of the containerized deployments and reducing the > > traditional scenario coverage. > > > > As we switch over to containerized services by default, we would also > > begin to reduce installed software on the overcloud images that we > > currently use. We have an open item to better understand how we can > > switch away from the golden images to a traditional software install > > process during the deployment and make sure this is properly tested. > > In theory it should work today by switching the default for > > EnablePackageInstall[0] to true and configuring repositories, but this > > is something we need to verify. > > > > If anyone has any objections to this default switch, please let us know. > > I think this is a great initiative. It would be nice to share some of > the TripleO experience in containerized deployments so that we can use > Puppet for containerized deployments. Perhaps we can work together on > adding some classes which can help deploy and configure containerized > services with Puppet. > > > > > Thanks, > > -Alex > > > > [0] https://github.com/openstack/tripleo-heat-templates/blob/ > master/puppet/services/tripleo-packages.yaml#L33-L36 > > > > ___ > > OpenStack-operators mailing list > > openstack-operat...@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > ______ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Shake 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
Re: [openstack-dev] [tc][fuel] Making Fuel a hosted project
HI Vikash I think Kolla is suitable for official project for deployment On Fri, Jun 16, 2017 at 1:02 PM, Vikash Kumar < vikash.ku...@oneconvergence.com> wrote: > I strongly believe Openstack must have any one official project for > deployment whether its Fuel or anything else. Cutting it short, talking to > number of people across industry/academic/government institutions, got a > sense that its necessary that there should be a official tool more than > Devstack for deployment. > > Regards, > Vikash > > On Fri, Jun 16, 2017 at 2:20 AM, Dean Troyer wrote: > >> On Thu, Jun 15, 2017 at 10:33 AM, Jay Pipes wrote: >> > I'd fully support the removal of all deployment projects from the >> "official >> > OpenStack projects list". >> >> Nice to hear Jay! :) >> >> It was intentional from the beginning to not be in the deployment >> space, we allowed those projects in (not unanimously IIRC) and most of >> them did not evolve as expected. >> >> I would not mind picking one winner and spending effort making an >> extremely easy, smooth, upgradable install that is The OneTrue >> OpenStack, I do not expect us to ever agree what that will look like >> so it is effectively never going to happen. We've seen how far >> single-vendor projects have gone, and none of them reached that level. >> >> dt >> >> -- >> >> Dean Troyer >> dtro...@gmail.com >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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 > > -- Shake 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
Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology
ance.openstack.org/tc/reference/tags/index.html >> >> -- >> Thierry Carrez (ttx) >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.op >> enstack.org?subject:unsubscribe >> <http://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:unsubscrib >> e >> 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 > -- Shake 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
Re: [openstack-dev] [Heat] Heat template example repository
I like it. the heat template is very old ,need to update. On Thu, May 11, 2017 at 4:54 AM, Lance Haig wrote: > Hi, > > I would like to introduce myself to the heat team. > > My name is Lance Haig I currently work for Mirantis doing workload > onboarding to openstack. > > Part of my job is assisting customers with using the new Openstack cloud > they have been given. > > I recently gave a talk with a colleague Florin Stingaciu on LCM with heat > at the Boston Summit. > > I am interested in assisting the project. > > We have noticed that there are some outdated examples in the heat-examples > repository and I am not sure that they all still function. > > I was wondering if it would be valuable for me to take a look at these and > fix them or perhaps we can rethink how we present the examples. > > I am interested in what you guys think. > > Thanks > > Lance > > __ > 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 > > -- Shake 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
Re: [openstack-dev] [tc][keystone][tacker]
Hi why not use barbican? On Sun, Mar 12, 2017 at 10:33 PM, yanxin...@cmss.chinamobile.com < yanxin...@cmss.chinamobile.com> wrote: > > Hi, folks: > > Currently tacker server node stores fernet keys for vim > password decryption on local root file system. > If Tacker service serves API requests through a load balancer, > then the operation will fail if the request > is not fulfilled by the server node which created and > stored the fernet key. > So we need a possible solution for syncing the keys > across multiple server nodes. Currently we are > thinking about storing the fernet keys via ceph or swift. > Do you have any suggestions on this approach, or does other project has > already dealt with this problem? > > 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 > > -- Shake 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-dev] [Networking-vSphere] whether support Ocata ?
Hi Networking-vSphere Team Networking-vSphere project whether support Ocata. I check the github, only have tag Mitaka? what about the Ocata? -- Shake 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
Re: [openstack-dev] [nova][puppet][tripleo][kolla][fuel] Let's talk nova cell v2 deployments and upgrades
Kolla now add cell support. hope can help review. https://review.openstack.org/#/c/418116/ On Sat, Jan 14, 2017 at 8:56 AM, Matt Riedemann wrote: > On 1/13/2017 2:05 PM, Matt Riedemann wrote: > >> >> Documenting this is going to be a priority. We should have something up >> for review in Nova by next week (like Monday), at least a draft. >> >> > Dan Smith has a start on the docs here: > > https://review.openstack.org/#/c/420198/ > > > -- > > Thanks, > > Matt Riedemann > > > __ > 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 > -- Shake 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
Re: [openstack-dev] [kolla] the alternative of log processing tool
Thanks for quick reply. so I think the snap is not good choice。 For end user, hope the solustion is mature and easy maintain. as discuss before, I'll put on my operator hat and would like to give my +1 to keep ELK instead of Heka. http://lists.openstack.org/pipermail/openstack-dev/2016-January/083974.html On Sun, Nov 27, 2016 at 11:09 PM, Michał Jastrzębski wrote: > It's in development > > On 27 November 2016 at 08:50, Shake Chen wrote: > > Hi Michal > > > > the snap seem not support log forward now, I can not find any infomation > in > > google . > > > > On Sun, Nov 27, 2016 at 9:46 PM, Michał Jastrzębski > > wrote: > >> > >> Hey, > >> > >> I am also working with Snap community to enable log forwarding with it > >> [1]. > >> Snap is super lightweight and additional benefit of this solution > >> would be that it can also handle monitoring, which was it's initial > >> role. One service to handle both would be elegant. I'll keep you > >> posted but let's not throw away this idea just yet. > >> > >> Cheers, > >> Michal > >> > >> [1] https://github.com/intelsdi-x/snap > >> > >> On 26 November 2016 at 23:55, Jeffrey Zhang > >> wrote: > >> > Heka is marked deprecated in Kolla during Newton cycle[0]. And Now we > >> > have a > >> > blueprint for this[1]. Two alternatives, fluentd[3] and Filebeat. > >> > > >> > For Filebeat, it is just a replacement of logstash-forward[2]. It is > not > >> > intent > >> > to replace the Logstash at all. > >> > > >> >> Filebeat is based on the Logstash Forwarder source code and replaces > >> >> Logstash > >> >> Forwarder as the method to use for tailing log files and forwarding > >> >> them > >> >> to > >> >> Logstash. > >> > > >> > Fillebeat is a log transport tool rather than log processing too. I do > >> > not > >> > treat it as an alternative at all. > >> > > >> > To be honest, I'd like back to Logstash, and Logstash 5.x is released > >> > with > >> > high > >> > performance improvement[4]. > >> > > >> >> In our performance testing, we've seen consistent throughput > increases > >> >> across multiple configurations. In some cases, we observed up to 75% > >> >> increase in events processed through Logstash. > >> > > >> > another benefit to using Logstash is the whole ELK stack is maintained > >> > by > >> > one > >> > community/company. It is well tested and easy to upgrade the whole > stack > >> > at > >> > the > >> > same time. Using other tools may force us on certain elasticsearch > >> > release. > >> > > >> > So, I think we have to alternative tools. > >> > > >> > * Fluentd > >> > * Logstash > >> > > >> > IMO, we need to make the decision and at least prepare the migration > >> > solution now. > >> > > >> > [1] https://blueprints.launchpad.net/kolla/+spec/heka-deprecation > >> > [2] > >> > > >> > https://www.elastic.co/guide/en/beats/filebeat/current/ > migrating-from-logstash-forwarder.html > >> > [3] http://www.fluentd.org/ > >> > [4] https://www.elastic.co/blog/logstash-5-0-0-released > >> > > >> > -- > >> > Regards, > >> > Jeffrey Zhang > >> > Blog: http://xcodest.me > >> > > >> > > >> > > __ > >> > 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 > > > > > > > > > > -- > > Shake 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 > -- Shake 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
Re: [openstack-dev] [kolla] the alternative of log processing tool
Hi Michal the snap seem not support log forward now, I can not find any infomation in google . On Sun, Nov 27, 2016 at 9:46 PM, Michał Jastrzębski wrote: > Hey, > > I am also working with Snap community to enable log forwarding with it [1]. > Snap is super lightweight and additional benefit of this solution > would be that it can also handle monitoring, which was it's initial > role. One service to handle both would be elegant. I'll keep you > posted but let's not throw away this idea just yet. > > Cheers, > Michal > > [1] https://github.com/intelsdi-x/snap > > On 26 November 2016 at 23:55, Jeffrey Zhang > wrote: > > Heka is marked deprecated in Kolla during Newton cycle[0]. And Now we > have a > > blueprint for this[1]. Two alternatives, fluentd[3] and Filebeat. > > > > For Filebeat, it is just a replacement of logstash-forward[2]. It is not > > intent > > to replace the Logstash at all. > > > >> Filebeat is based on the Logstash Forwarder source code and replaces > >> Logstash > >> Forwarder as the method to use for tailing log files and forwarding them > >> to > >> Logstash. > > > > Fillebeat is a log transport tool rather than log processing too. I do > not > > treat it as an alternative at all. > > > > To be honest, I'd like back to Logstash, and Logstash 5.x is released > with > > high > > performance improvement[4]. > > > >> In our performance testing, we've seen consistent throughput increases > >> across multiple configurations. In some cases, we observed up to 75% > >> increase in events processed through Logstash. > > > > another benefit to using Logstash is the whole ELK stack is maintained by > > one > > community/company. It is well tested and easy to upgrade the whole stack > at > > the > > same time. Using other tools may force us on certain elasticsearch > release. > > > > So, I think we have to alternative tools. > > > > * Fluentd > > * Logstash > > > > IMO, we need to make the decision and at least prepare the migration > > solution now. > > > > [1] https://blueprints.launchpad.net/kolla/+spec/heka-deprecation > > [2] > > https://www.elastic.co/guide/en/beats/filebeat/current/ > migrating-from-logstash-forwarder.html > > [3] http://www.fluentd.org/ > > [4] https://www.elastic.co/blog/logstash-5-0-0-released > > > > -- > > Regards, > > Jeffrey Zhang > > Blog: http://xcodest.me > > > > > __ > > 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 > -- Shake 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
Re: [openstack-dev] [cloudkitty] Proposing Pierre-Alexandre Bardina (pabardina) as core for cloudkitty
Thanks for your reply. Hope the Cloudkitty core review team can more active https://review.openstack.org/#/q/project:openstack/cloudkitty+status:open On Tue, Oct 18, 2016 at 10:49 PM, Christophe Sauthier < christophe.sauth...@objectif-libre.com> wrote: > Ho Shake, > > Thanks for your feedback !!! > > It is true (that all core so far are from the same company). On the other > hand there are only 3 cores... > > The thing is in the past we haven't been unable to get a contributor on a > "long period of time" outside the company... Which is the reason why so far > it is single-vendor... But I am confident that it will change quite soon : > I am currently waiting just a few more weeks to propose another > contributor, from another company this time, who has been active on the > project for a few monts. > > Regarding Pierre-Alexandre proposal, he has been in charge of the > integration with horizon for whatever we needed (which was more the case on > the mitaka cycle). That is why I really think it would be a very good idea > for the project to give him core reviewers rights... > > All the best, > > Christophe > > > > Christophe Sauthier Mail : > christophe.sauth...@objectif-libre.com > CEO Mob : +33 (0) 6 16 98 63 96 > Objectif LibreURL : www.objectif-libre.com > Au service de votre Cloud Twitter : @objectiflibre > > Suivez les actualités OpenStack en français en vous abonnant à la Pause > OpenStack > http://olib.re/pause-openstack > > Le 2016-10-18 15:19, Shake Chen a écrit : > >> Hi >> >> All the Cores member are same company, seem not good idea. >> >> only 5 revew, 1 commit. >> >> On Tue, Oct 18, 2016 at 7:27 PM, Guillaume Espanel >> wrote: >> >> +1 >>> >>> -- >>> Guillaume Espanel >>> Objectif Libre www.objectif-libre.com [3] >>> Infrastructure et Formations Linux >>> >>> Le 2016-10-18 13:16, Christophe Sauthier a écrit : >>> >>> Hello developer mailing list folks, >>>> >>>> I'd like to propose that we add Pierre-Aexandre Bardina (pabardina) >>>> as an OpenStack cloudkitty >>>> core reviewer. >>>> >>>> He has been a member of our community for a long time, contributing >>>> very seriously in cloudkitty especially on the integration of >>>> cloudkitty in Horizon (cloudkitty-dashboard) >>>> He also provided some reviews on that part (well reviews for work >>>> that he hasn't provided...) [1] >>>> >>>> Overall I think Pierre-Alexandre would make a great addition to the >>>> core review team. >>>> >>>> Current Cloudkitty cores, please respond with +1/-1. >>>> >>>> All the best, >>>> >>>> Christophe >>>> >>>> http://stackalytics.com/report/contribution/cloudkitty-dashboard/90 [1] >>>> >>>> >>>> Christophe Sauthier Mail : >>>> christophe.sauth...@objectif-libre.com >>>> CEO Mob : +33 (0) 6 16 98 63 96 >>>> [2] >>>> Objectif LibreURL : www.objectif-libre.com >>>> [3] >>>> Au service de votre Cloud Twitter : @objectiflibre >>>> >>>> Suivez les actualités OpenStack en français en vous abonnant à la >>>> Pause OpenStack >>>> http://olib.re/pause-openstack [4] >>>> >>>> >>>> __ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: openstack-dev-requ...@lists.op >>>> enstack.org?subject:unsubscribe [5] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [6] >>>> >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.op >>> enstack.org?subject:unsubscribe [5] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [6] >>> >> >> -- >> >> Shake Chen >> >> >> >> Links: >> -- >> [1] http://stackalytics.com/report/contribution/cloudkitty-dashboard/90 >> [2] tel:%2B33%20%280%29%206%2016%2098%206
Re: [openstack-dev] [cloudkitty] Proposing Pierre-Alexandre Bardina (pabardina) as core for cloudkitty
Hi All the Cores member are same company, seem not good idea. only 5 revew, 1 commit. On Tue, Oct 18, 2016 at 7:27 PM, Guillaume Espanel < guillaume.espa...@objectif-libre.com> wrote: > +1 > > -- > Guillaume Espanel > Objectif Libre www.objectif-libre.com > Infrastructure et Formations Linux > > > Le 2016-10-18 13:16, Christophe Sauthier a écrit : > >> Hello developer mailing list folks, >> >> I'd like to propose that we add Pierre-Aexandre Bardina (pabardina) >> as an OpenStack cloudkitty >> core reviewer. >> >> He has been a member of our community for a long time, contributing >> very seriously in cloudkitty especially on the integration of >> cloudkitty in Horizon (cloudkitty-dashboard) >> He also provided some reviews on that part (well reviews for work >> that he hasn't provided...) [1] >> >> Overall I think Pierre-Alexandre would make a great addition to the >> core review team. >> >> Current Cloudkitty cores, please respond with +1/-1. >> >> All the best, >> >> Christophe >> >> >> >> http://stackalytics.com/report/contribution/cloudkitty-dashboard/90 >> >> >> >> Christophe Sauthier Mail : >> christophe.sauth...@objectif-libre.com >> CEO Mob : +33 (0) 6 16 98 63 96 >> Objectif LibreURL : www.objectif-libre.com >> Au service de votre Cloud Twitter : @objectiflibre >> >> Suivez les actualités OpenStack en français en vous abonnant à la >> Pause OpenStack >> http://olib.re/pause-openstack >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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 > -- Shake 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
Re: [openstack-dev] [requirements][FFE] block graphviz 0.5.0
seem the link is error. https://review.openstack.org/#/c/367740/ On Fri, Sep 9, 2016 at 2:28 PM, Swapnil Kulkarni (coolsvap) wrote: > Currently kolla gate jobs are failing due to issues in graphviz 0.5.0. [1] > > We need to unblock the gates by blocking graphviz===0.5.0. > > [1] https://review.openstack.org/#/c/367416/ > > -- > Best Regards, > Swapnil Kulkarni > irc : coolsvap > > __ > 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 > -- Shake 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
Re: [openstack-dev] [devstack] some compress error when deploy OS
hope can help you.
http://www.chenshake.com/openstack-project-series-3-devstack/
On Fri, Jul 22, 2016 at 9:35 AM, wrote:
>
> Hi all,
>
> When i use devstack to deploy a OS env, it raise the error.
> The log is as follows.
> Does anybody know how to resolve this problem? Thank you!~
>
> 12 static files copied to '/opt/stack/horizon/static', 1708 unmodified.
> +lib/horizon:init_horizon:152
> DJANGO_SETTINGS_MODULE=openstack_dashboard.settings
> +lib/horizon:init_horizon:152 django-admin compress --force
> Found 'compress' tags in:
>
> /opt/stack/horizon/openstack_dashboard/templates/horizon/_scripts.html
> /opt/stack/horizon/openstack_dashboard/templates/horizon/_conf.html
> /opt/stack/horizon/openstack_dashboard/templates/_stylesheets.html
> Compressing... CommandError: An error occurred during rendering
> /opt/stack/horizon/openstack_dashboard/templates/horizon/_scripts.html:
> '\"../build/dagre-d3.js\"' isn't accessible via COMPRESS_URL
> ('/dashboard/static/') and can't be compressed
> +lib/horizon:init_horizon:1exit_trap
> +./stack.sh:exit_trap:480 local r=1
>
>
> BR,
> dwj
>
>
>
>
> ZTE Information Security Notice: The information contained in this mail (and
> any attachment transmitted herewith) is privileged and confidential and is
> intended for the exclusive use of the addressee(s). If you are not an
> intended recipient, any disclosure, reproduction, distribution or other
> dissemination or use of the information contained is strictly prohibited. If
> you have received this mail in error, please delete it and notify us
> immediately.
>
>
>
>
> __
> 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
>
>
--
Shake 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
Re: [openstack-dev] [kolla] Cinder Problem w/ AIO install
Hi
seem kolla cinder now only support Ceph, not support LVM.
On Mon, Jun 6, 2016 at 5:50 AM, Arash Kaffamanesh wrote:
> Hi,
>
> I'm trying to install OpenStack via kolla on a single bare metal machine
> following this page:
>
> http://docs.openstack.org/developer/kolla/quickstart.html
>
> After the install I can log into horizon, but obviously since cinder is
> missing, I can't launch any instance (block device is missing).
>
> So I tried to activate cinder and set in globals.yml:
> (created a loopback device following this guide:
> http://docs.openstack.org/developer/kolla/cinder-guide.html)
>
> enable_cinder: "yes"
>
> cinder_iscsi_ip_address: "x.x.x.x"
>
> cinder_volume_group: "cinder-volumes"
>
> After running kolla-ansible deploy, I'm getting the following exception
> below by the task copying over cinder.conf:
> Any ideas?
>
> Thanks for any hints in advance!
> -Arash
>
>
> ###
>
> TASK [cinder : Copying over cinder.conf]
> ***
>
> An exception occurred during task execution. To see the full traceback,
> use -vvv. The error was: [line 57]: '[]\n'
>
> fatal: [localhost]: FAILED! => {"failed": true, "stdout": ""}
>
>
> PLAY RECAP
> *
>
> localhost : ok=184 changed=1unreachable=0
> failed=1
>
>
> Command failed ansible-playbook -i
> /usr/share/kolla/ansible/inventory/all-in-one -e @/etc/kolla/globals.yml -e
> @/etc/kolla/passwords.yml -e CONFIG_DIR=/etc/kolla -e action=deploy
> /usr/share/kolla/ansible/site.yml
>
> PLAY RECAP
> *
>
> localhost : ok=184 changed=1unreachable=0
> failed=1
>
> ###
>
> ______
> 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
>
>
--
Shake 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
Re: [openstack-dev] Call for Commiters & Contributors for daisycloud-core project
Hi Zhijiang I think you can put Daisy into docker, then use ansible or kolla deploy Daisy. On Tue, May 31, 2016 at 9:43 AM, wrote: > Hi All, > > I would like to introduce to you a new OpenStack installer project > Daisy(project name: daisycloud-core). Daisy used to be a closed source > project mainly developed by ZTE, but currently we make it a OpenStack > related project(http://www.daisycloud.org, > https://github.com/openstack/daisycloud-core). > > Although it is not mature and still under development, Daisy concentrates > on deploying OpenStack fast and efficiently for large data center which has > hundreds of nodes. In order to reach that goal, Daisy was born to focus on > many features that may not be suitable for small clusters, but definitely > conducive to the deployment of big clusters. Those features include but not > limited to the following: > > 1. Containerized OpenStack Services > In order to speed up installation and upgrading as a whole, Daisy decides > to use Kolla as underlying deployment module to support containerized > OpenStack services. > > 2. Multicast > Daisy utilizes multicast as much as possible to speed up imaging work flow > during the installation. For example, instead of using centralized Docker > registry while adopting Kolla, Daisy multicasts all Docker images to each > node of the cluster, then creates and uses local registries on each node > during Kolla deployment process. The Same things can be done for OS imaging > too. > > 3. Automatic Deployment > Instead of letting users decide if a node can be provisioned and deserved > to join to the cluster, Daisy provide a characteristics matching mechanism > to recognize if a new node has the same capabilities as a current working > computer nodes. If it is true, Daisy will start deployment on that node > right after it is discovered and make it a computer node with the same > configuration as that current working computer nodes. > > 4. Configuration Template > Using precise configuration file to describe a big dynamic cluster is not > applicable, and it is not able to be reused when moving to another > approximate environment either. Daisy’s configuration template only > describes the common part of the cluster and the representative of the > controller/compute nodes. It can be seen as a semi-finished configuration > file which can be used in any approximate environments. During deployment, > users only have to evaluate few specific parameters to make the > configuration template a final configuration file. > > 5. Your comments on anything else that can brings unique value to the > large data center deployment? > > As the project lead, I would like to get feedback from you about this new > project. You are more than welcome to join this project! > > Thank you > Zhijiang > > > > ZTE Information Security Notice: The information contained in this mail (and > any attachment transmitted herewith) is privileged and confidential and is > intended for the exclusive use of the addressee(s). If you are not an > intended recipient, any disclosure, reproduction, distribution or other > dissemination or use of the information contained is strictly prohibited. If > you have received this mail in error, please delete it and notify us > immediately. > > > > > __ > 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 > > -- Shake 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
Re: [openstack-dev] [fuel] Fuel 8.0 is released
Hi any plan support install Openstack controller in CentOS 7.x? On Wed, Mar 2, 2016 at 10:20 AM, Dmitry Borodaenko wrote: > We are proud to announce the release of Fuel 8.0, deployment and > management tool for OpenStack. > > This release initroduces support for OpenStack Liberty, adds a number of > exciting new features and enhancements, fixes over 1600 bugs, and > eliminates a great deal of technical debt. > > Some highlights: > > - Support for multi-rack deployments with L3 routing between racks that > was first introduced in Fuel 6.0 was expanded with more automation and > validation; some key limitations of the previous implementation, such > as placing all VIPs, floating IPs, and controllers in a single rack, > have been relaxed (although controller services failover across racks > still needs extra work); node groups can now be managed via Fuel UI. > > - Fuel master node now runs on CentOS 7 with Python 2.7. > > - The bootstrap image used for node discovery and provisioning is now > generated when Fuel node is setup, and can be dynamically rebuilt to > include additional drivers. This unifies the kernel version from > discovery to a working install, removing a whole host of possible > compatibility issues > > - As another small step towards enabling life cycle management, a > limited set of cloud configuration parameters can now be changed after > deployment. This includes changing configuration of OpenStack services > and installation of additional software via plugins. > > Learn more about Fuel: > https://wiki.openstack.org/wiki/Fuel > > How we work: > https://wiki.openstack.org/wiki/Fuel/How_to_contribute > > Specs for features in 8.0 and other Fuel releases: > http://specs.openstack.org/openstack/fuel-specs/ > > ISO image: > > http://seed.fuel-infra.org/fuelweb-community-release/fuel-community-8.0.iso.torrent > > RPM packages: > http://mirror.fuel-infra.org/mos-repos/centos/mos8.0-centos7-fuel/ > > Great work Fuel team, thanks to everyone who contributed to this awesome > release! > > -- > Dmitry Borodaenko > > __ > 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 > -- Shake 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-dev] [devstack]what is different of stack-volumes-default and stack-volumes-lvmdriver-1
Hi I try to install devstack and enable cinder service. before , would create a volume for cinder. but now I found the devstack would create two VG:stack-volumes-lvmdriver-1 and stack-volumes-default. I check the cat /etc/cinder/cinder.conf and found the setting [lvmdriver-1] lvm_type = default iscsi_helper = tgtadm volume_group = stack-volumes-lvmdriver-1 volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver volume_backend_name = lvmdriver-1 but I can not found any setting for stack-volumes-default. who can told me what the use for VG of stack-volumes-default ? -- Shake 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
Re: [openstack-dev] OpenStack installer
whether is possible use Tower to manage it? On Tue, Jan 26, 2016 at 6:32 PM, Gyorgy Szombathelyi < gyorgy.szombathe...@doclerholding.com> wrote: > Hello! > > I just want to announce a new installer for OpenStack: > https://github.com/DoclerLabs/openstack > It is GPLv3, uses Ansible (currently 1.9.x, 2.0.0.2 has some bugs which > has to be resolved), has lots of components integrated (of course there are > missing ones). > Goal was simplicity and also operating the cloud, not just installing it. > We started with Rackspace's openstack-ansible, but found it a bit complex > with the containers. Also it didn't include all the components we required, > so started this project. > Feel free to give it a try! The documentation is sparse, but it'll improve > with time. > (Hope you don't consider it as an advertisement, we don't want to sell > this, just wanted to share our development). > > Br, > György > > __ > 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 > -- Shake 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
Re: [openstack-dev] [infra][stackalytics] some projects not visible in stackalytics now
seem some project not update many day.like http://stackalytics.com/?project_type=openstack&module=kolla-group the data still stay 02 Jan 2016 On Thu, Jan 7, 2016 at 5:02 PM, joehuang wrote: > Hello, > > > > Both Kingbird[1] and Tricircle[2] are not visible in stackalytics.com > now, which are projects under OpenStack name space. Some days ago these > two projects are listed in > http://stackalytics.com/?project_type=openstack-others > > > > Maybe I missed some mail, don’t know what happened, or something wrong in > configuration in Infra or stackalytics? > > > > [1] https://github.com/openstack/kingbird/ > > [2] https://github.com/openstack/tricircle > > > > Best Regards > > Chaoyi Huang ( Joe Huang ) > > __ > 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 > > -- Shake 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
Re: [openstack-dev] Well-tested guides for OpenStack Icehouse installation and Instance creation with Neutron
Hi hope can add the cinder and Ceilometer. On Wed, Aug 6, 2014 at 3:27 AM, chayma ghribi wrote: > > Hi all, > > > I want to share with you our well tested OpenStack Icehouse Installation > Guide for Ubuntu 14.04. > > > https://github.com/ChaimaGhribi/OpenStack-Icehouse-Installation/blob/master/OpenStack-Icehouse-Installation.rst > > If you want to create your first instance with Neutron, follow the > instructions in our VM creation guide available here: > > > https://github.com/ChaimaGhribi/OpenStack-Icehouse-Installation/blob/master/Create-your-first-instance-with-Neutron.rst > > Hope this will be helpful ! > Your questions and suggestions are welcome :) > > > Regards, > > Chaima Ghribi > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Shake Chen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Step by step OpenStack Icehouse Installation Guide
Hi maybe you can consider use script create Database and endpoint. like https://github.com/EmilienM/openstack-folsom-guide/tree/master/scripts this would be easy for user. On Tue, Aug 5, 2014 at 12:38 AM, chayma ghribi wrote: > Hi ! > > Thank you for the comment Qiming ! > > The script stack.sh is used to configure Devstack and to assign the > heat_stack_owner role to users. > Also, I think that Heat is configured by default on Devstack for icehouse. > > http://docs.openstack.org/developer/heat/getting_started/on_devstack.html#configure-devstack-to-enable-heat > > In our guide we are not installing using devstack. > We are creating and managing stacks with Heat but we have not errors ! > > If you have some examples of tests (or scenarios) that helps us to > identify errors and improve the guide, please don't hesitate to contact us > ;) > All your contributions are welcome :) > > Regards, > > Chaima Ghribi > > > > > > 2014-08-04 8:13 GMT+02:00 Qiming Teng : > > Thanks for the efforts. Just want to add some comments on installing >> and configuring Heat, since an incomplete setup may cause bizarre >> problems later on when users start experiments. >> >> Please refer to devstack script below for proper configuration of Heat: >> >> https://github.com/openstack-dev/devstack/blob/master/lib/heat#L68 >> >> and the function create_heat_accounts at the link below which helps >> create the required Heat accounts. >> >> https://github.com/openstack-dev/devstack/blob/master/lib/heat#L214 >> >> Regards, >> Qiming >> >> On Sun, Aug 03, 2014 at 12:49:22PM +0200, chayma ghribi wrote: >> > Dear All, >> > >> > I want to share with you our OpenStack Icehouse Installation Guide for >> > Ubuntu 14.04. >> > >> > >> https://github.com/ChaimaGhribi/OpenStack-Icehouse-Installation/blob/master/OpenStack-Icehouse-Installation.rst >> > >> > An additional guide for Heat service installation is also available ;) >> > >> > >> https://github.com/MarouenMechtri/OpenStack-Heat-Installation/blob/master/OpenStack-Heat-Installation.rst >> > >> > Hope this manuals will be helpful and simple ! >> > Your contributions are welcome, as are questions and suggestions :) >> > >> > Regards, >> > Chaima Ghribi >> >> >> >> ___ >> 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 > > -- Shake Chen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] 答复: 答复: [Nova][Neutron][Cinder][Heat]Should we support tags for os resources?
Now the HPcloud provide Tag feature, now can tag the vm. maybe we study how to achieve the feature in HPcloud. On Tue, Apr 22, 2014 at 10:02 AM, Huangtianhua wrote: > Thanks very much. > > > > I have register the blueprints for nova. > > https://blueprints.launchpad.net/nova/+spec/add-tags-for-os-resources > > > > The simple plan is: > > 1. Add the tags api (create tags/delete tags/describe tags) for v3 > api > > 2. Change the implement for instance from “metadata” to “tags” > > > > Your suggestions? > > > > Thanks > > *发件人:* Jay Pipes [mailto:jaypi...@gmail.com] > *发送时间:* 2014年4月22日 3:46 > *收件人:* OpenStack Development Mailing List (not for usage questions) > *主题:* Re: [openstack-dev] 答复: [Nova][Neutron][Cinder][Heat]Should we > support tags for os resources? > > > > Absolutely. Feel free. > > > > On Mon, Apr 21, 2014 at 4:48 AM, Huangtianhua > wrote: > > I plan to register a blueprints in nova for record this. Can I? > > > -邮件原件- > 发件人: Jay Pipes [mailto:jaypi...@gmail.com] > 发送时间: 2014年4月20日 21:06 > 收件人: openstack-dev@lists.openstack.org > 主题: Re: [openstack-dev] [Nova][Neutron][Cinder][Heat]Should we support > tags for os resources? > > > On Sun, 2014-04-20 at 08:35 +, Huangtianhua wrote: > > Hi all: > > > > Currently, the EC2 API of OpenStack only has tags support (metadata) > > for instances. And there has already a blueprint about to add support > > for volumes and volume snapshots using “metadata”. > > > > There are a lot of resources such as > > image/subnet/securityGroup/networkInterface(port) are supported add > > tags for AWS. > > > > I think we should support tags for these resources. There may be no > > property “metadata" for these resources, so we should to add > > “metadata” to support the resource tags, the change related API. > > Hi Tianhua, > > In OpenStack, generally, the choice was made to use maps of key/value > pairs instead of lists of strings (tags) to annotate objects exposed in the > REST APIs. OpenStack REST APIs inconsistently call these maps of key/value > pairs: > > * "properties" (Glance, Cinder Image, Volume respectively) > * "extra_specs" (Nova InstanceType) > * "metadata" (Nova Instance, Aggregate and InstanceGroup, Neutron) > * "metadetails" (Nova Aggregate and InstanceGroup) > * "system_metadata" (Nova Instance -- differs from "normal" metadata in > that the key/value pairs are 'owned' by Nova, not a user...) > > Personally, I think tags are a cleaner way of annotating objects when the > annotation is coming from a normal user. Tags represent by far the most > common way for REST APIs to enable user-facing annotation of objects in a > way that is easy to search on. I'd love to see support for tags added to > any searchable/queryable object in all of the OpenStack APIs. > > I'd also like to see cleanup of the aforementioned inconsistencies in how > maps of key/value pairs are both implemented and named throughout the > OpenStack APIs. Specifically, I'd like to see this implemented in the next > major version of the Compute API: > > * Removal of the "metadetails" term > * All key/value pairs can only be changed by users with elevated > privileged system-controlled (normal users should use tags) > * Call all these key/value pair combinations "properties" -- technically, > "metadata" is "data about data", like the size of an integer. These > key/value pairs are just data, not data about data. > * Identify key/value pairs that are relied on by all of Nova to be a > specific key and value combination, and make these things actual real > attributes on some object model -- since that is a much greater guard for > the schema of an object and enables greater performance by allowing both > type safety of the underlying data and removes the need to search by both a > key and a value. > > Best, > -jay > > > ___ > 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 mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Shake Chen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] User registrations
the most important is the user can get back password, modify own email address. On Mon, Nov 11, 2013 at 2:31 PM, Lyle, David wrote: > I think there is certainly interest. I do think it will need to be highly > configurable to be useful. The problem, as Dolph points out, is that each > deployment has its own workflow. > > Points of configuration: > -Does the local keystone deployment policy support self-registration? The > default is no. So, at that point access to self-registration should be > hidden. > > -How many steps are required in the registration process? > > -Is payment information required? Address? > > -How is the registration confirmed, email, text, ? > > -CAPTCHA? > > I think the two main reasons such a facility is not present in Horizon are: > 1. Until recently determining keystone's access policy was not possible. > 2. The actual implementation is highly deployment dependent. > > -David > > From: Dolph Mathews [mailto:dolph.math...@gmail.com] > Sent: Monday, November 11, 2013 8:57 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [horizon] User registrations > > So, there's a bunch of use case questions here where I suspect there are > no correct answers (so preferences will vary per deployment). The first > ones that come to mind- > > Are the users accessing this web form trusted or untrusted? > > Do they need to be verified, somehow? Are they going to be billed for > their resource consumption? > > After registration, should they own their own domain in keystone? Or be > assigned their own project in an existing domain? Or simply be added to an > existing group with limited authorization? > > On Sun, Nov 10, 2013 at 6:26 PM, Paul Belanger < > paul.belan...@polybeacon.com> wrote: > Greeting, > > In a previous thread I talked about building an application atop of > horizon and keystone. So far things are working out pretty well. One > thing I have been trying to figure out is how to move forward with > user registration for the horizon application. A few moons ago, IIRC, > horizon actually use django-registration however the move to Keystone > removed that functionality. > > For me, I'd like to expose some functionality within my web > application allow users to register vs having an admin provisioning > accounts. > > So, I'm curious if there is anything interest in having such a module > back in horizon but leveraging keystone this time around. I'm actually > curious to hear how people see this working since this is the next > thing I need to deal with. > > -- > Paul Belanger | PolyBeacon, Inc. > Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) > Github: https://github.com/pabelanger | Twitter: > https://twitter.com/pabelanger > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > > -Dolph > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Shake Chen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] PTL Candidacy
I think many people like me want to know the plan, when can remove Nova network？ On Sat, Sep 21, 2013 at 4:44 AM, Mark McClain wrote: > > Hi- > > I writing to announce my candidacy for the OpenStack Networking (Neutron) > PTL. > > I am the current Neutron PTL. Our team continued to grow during the > Havana cycle and both existing and new contributors worked to deliver > double the number of blueprints than the previous release. Our vibrant > ecosystem makes me excited for the future of Neutron and I would love to > continue as the PTL. > > Qualifications > --- > > I am a Neutron core developer with 13 years of commercial Python > development experience. During my career, I have developed and deployed > network applications based on the same underlying libraries used throughout > Neutron. I started contributing to Neutron project during the Essex > development cycle. In Folsom, I was promoted to core and was the primary > developer of the DHCP implementation and Neutron's network namespace > library. During Grizzly, I worked on the metadata service, database > migrations, and LBaaS reference implementation. > > Havana Accomplishments > > > During the Havana cycle, I worked as a developer, core team member, and a > technical lead. > > - Planned and implemented the Quantum to Neutron name change. > - Most active reviewer on the Neutron team ( > http://russellbryant.net/openstack-stats/neutron-reviewers-180.txt) > - Organized the Networking track at the Havana Design Summit. > - Led bug triaging and sub-team assignment. > - Interfaced with vendors new to Neutron and helped in the integration of > their plugins. > - Assisted members of the community to further their understanding of > Neutron and improve Python development best practices. > - Promoted Neutron by delivering presentations at conferences and regional > meet ups worldwide. > > > Icehouse > - > > During the Icehouse development cycle, I'd like to see the team focus on: > > - Continuing to grow the community of contributors and code reviewers. > - Improving documentation for both deployers and developers. > - Build upon the services added in Havana to extend and improve load > balancing, firewalling, and VPN. > - Integrating plugins from vendors new to the community including FWaaS, > LBaaS, ML2, VPNaaS plugins/drivers. > - More efficient Neutron system testing and gating including full Tempest > testing. > - Further work to ease deploying at scale. > - Refactoring the API layer to leverage a common WSGI framework as other > OpenStack projects. > - Improving database resource modeling and extension management. > - Unified network service management framework. > - Continued support of the Horizon team to assist with Neutron integration. > - Defined migration path from nova-network to Quantum. > > I'd love the opportunity to continue as the PTL and work with the Neutron > team to fill in the gaps during the design summit in Hong Kong. > > Thanks, > mark > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Shake Chen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Candidacy for Compute (Nova) PTL
hon-novaclient >>- review all novaclient patches >>- ensure that novaclient blueprints get reviewed and bugs are triaged >>- build and lead a group of people interested in novaclient >> >> - nova bug triage lead >>- ensure bugs are triaged >>- ensure the highest priority bugs are discussed, either on the >> mailing list or in the weekly nova meeting >>- generate metrics on nova bugs >>- set goals for nova bug processing, and track our progress against >> the goals using the generated metrics >>- build and lead a group of people interested in helping nova by >> doing bug triage >> >> - nova-drivers team >>- (This actually already exists, but I think we could formalize >> responsibilities and make more use of it) >>- responsible for reviewing nova blueprints >>- ensure all blueprints have appropriate design documentation and fit >> within the overall project vision >>- regularly discuss blueprints with each other and the overall nova >> community via the mailing list and weekly meeting to ensure Nova >> has an accurate and high quality roadmap >> >> These positions could either be elected by the technical contributors to >> the Compute program (we sure love elections around here), or they could >> simply be appointed by the PTL (my preference, I think). >> >> >> * What do you think? >> >> Finally, I would like to know what you all think. What does the project >> need to improve on? >> >> What could I improve on if I were to be re-elected as the PTL? >> >> >> * Technical Matters >> >> I've used most of this message to focus on non-technical matters. That >> certainly does not mean that I do not have strong opinions on the >> technical future of Nova. In fact, I feel strongly that we need to >> continue to invest heavily in these areas: >> >>1) Upgrades >>2) Scale >>3) Security >> >> Upgrades - We have made ongoing progress towards supporting live rolling >> upgrades over the last few releases. We need to continue to push hard >> on this. >> >> http://summit.openstack.org/cfp/details/94 >> >> Scale - Nova is already being deployed at very large scale (10s of >> thousands of nodes). However, there are definitely pain points. I'd >> like to see more people working on cells support. Even within a cell >> there are things we could improve. For example, I'd like to see more >> progress toward supporting more scalable messaging, either by adding >> support for AMQP 1.0 which supports peer-to-peer messaging as well as >> brokered, or by continuing to enhance the existing ZeroMQ support. >> Enhancements to our database usage to make it more scalable are >> important, as well. >> >> Security - This is a priority for anyone deploying OpenStack, but >> especially in a public setting. One area we have had in our sights for >> a while is the use of trusted messaging. The infrastructure for this >> should be merged early Icehouse, so I'd like to see Nova adopt it and >> start making use of it as soon as possible. >> >> >> * Other References >> >> My patches: >> https://review.openstack.org/#/q/owner:rbry...@redhat.com,n,z >> >> My reviews: >> https://review.openstack.org/#/q/reviewer:rbry...@redhat.com,n,z >> >> Activity Board: >> >> http://activity.openstack.org/data/display/OPNSTK2/Technical+Contributors >> >> http://activity.openstack.org/data/pages/viewpage.action?pageId=3670022 >> >> Ohloh profile: >> https://www.ohloh.net/accounts/russellb >> >> >> *** >> >> I have had a blast working on OpenStack. It is truly an honor to work >> with so many talented people and to have been elected to help lead the >> effort. >> >> Thank you for your consideration, >> >> -- >> Russell Bryant >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Ravi > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Shake Chen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Wizard UI for modal workflow dialog
+1 On Sat, Sep 14, 2013 at 2:29 AM, Toshiyuki Hayashi wrote: > Hi, > > I just added BP Wizard UI for workflow. > https://blueprints.launchpad.net/horizon/+spec/wizard-ui-for-workflow > > [Screenshot] > https://dl.dropboxusercontent.com/u/7098/openstack/wizard.png > > [Demo movie] > http://www.youtube.com/watch?v=uCmhI0fbDYg&feature=youtu.be > > The current some workflow dialogs (which have many tabs) are difficult > to understand for users what to do. > Wizard UI is better to proceed and understand the tasks users should do. > I believe this feature enhances the UX of modal workflow dialog. > > If you have any comments and concerns, please let me know. > Also I started discussing on G+. > https://plus.google.com/u/0/110931099804484211859/posts/aMCU2CCzzZq > > > Regards, > Toshiyuki > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Shake Chen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [DevStack]
Now I try to install devstack in CentOS 6.4 and meet the error 2013-09-12 23:26:06 + screen -S stack -p g-api -X stuff 'cd /opt/stack/glance; /usr/bin/glance-api --config-file=/etc/glance/glance-api.conf || echo "g-api 'ailed to start" | tee "/opt/stack/status/stack/g-api.failure" 2013-09-12 23:26:06 + echo 'Waiting for g-api (10.1.199.8:9292) to start...' 2013-09-12 23:26:06 Waiting for g-api (10.1.199.8:9292) to start... 2013-09-12 23:26:06 + timeout 60 sh -c 'while ! http_proxy= wget -q -O- http://10.1.199.8:9292; do sleep 1; done' 2013-09-12 23:27:06 + die 195 'g-api did not start' 2013-09-12 23:27:06 + local exitcode=0 [root@node08 devstack]# 2013-09-12 23:27:06 + set +o xtrace 2013-09-12 23:27:06 [Call Trace] 2013-09-12 23:27:06 stack.sh:1159:start_glance 2013-09-12 23:27:06 /opt/stack/devstack/lib/glance:195:die 2013-09-12 23:27:06 [ERROR] /opt/stack/devstack/lib/glance:195 g-api did not start the other person in Ubuntu 12.04, also have same problem. -- Shake Chen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] General Question about CentOS
Now in Centos 6.x ,the Python is 2.6.6, the Openstack can run it. you can check the RDO http://openstack.redhat.com/Quickstart On Sat, Aug 17, 2013 at 8:05 AM, Yufang Zhang wrote: > My team has deployed hundreds of compute nodes on CentOS-5.4(with python26 > installed and Xen as hypervisor ) based on Folsom. It does work on our > production system :) > > > 2013/8/17 Miller, Mark M (EB SW Cloud - R&D - Corvallis) < > mark.m.mil...@hp.com> > >> Is OpenStack supported on CentOS running Python 2.6? >> >> ** ** >> >> Thanks, >> >> ** ** >> >> Mark >> >> ___ >> 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 > > -- Shake Chen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposal oslo.db lib
+1 What about the keystone status in oslo? On Fri, Aug 16, 2013 at 10:40 PM, David Ripton wrote: > On 08/16/2013 09:52 AM, Boris Pavlovic wrote: > > We (OpenStack contributors) done a really huge and great work around DB >> code in Grizzly and Havana to unify it, put all common parts into >> oslo-incubator, fix bugs, improve handling of sqla exceptions, provide >> unique keys, and to use this code in different projects instead of >> custom implementations. (well done!) >> >> oslo-incubator db code is already used by: Nova, Neutron, Cinder, >> Ironic, Ceilometer. >> >> In this moment we finished work around Glance: >> https://review.openstack.org/#**/c/36207/<https://review.openstack.org/#/c/36207/> >> >> And working around Heat and Keystone. >> >> So almost all projects use this code (or planing to use it) >> >> Probably it is the right time to start work around moving oslo.db code >> to separated lib. >> >> We (Roman, Viktor and me) will be glad to help to make oslo.db lib: >> >> E.g. Here are two drafts: >> 1) oslo.db lib code: >> https://github.com/malor/oslo.**db<https://github.com/malor/oslo.db> >> 2) And here is this lib in action: https://review.openstack.org/#** >> /c/42159/ <https://review.openstack.org/#/c/42159/> >> >> >> Thoughts? >> > > +1. Having to manually paste code from oslo-incubator into other projects > is error-prone. Of course it's important to get the library versioning > right and do releases, but that's a small cost imposed on just the oslo-db > folks to make using this code easier for everyone else. > > -- > David Ripton Red Hat drip...@redhat.com > > > ______**_ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.**org > http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > -- Shake Chen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Allows to set the memory parameters for an Instance
maybe use Extra Flavor . https://wiki.openstack.org/wiki/FlavorExtraSpecsKeyList On Sun, Aug 11, 2013 at 3:49 PM, Jae Sang Lee wrote: > > > I've registered a blueprint to allows to set the advanced memory > parameters for an Instance > > https://blueprints.launchpad.net/nova/+spec/libvirt-memtune-for-instance > > > Would it be possible to review it (and maybe get an approval or not)? > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Shake Chen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] Patching Horizon Code when installed using "apt-get install"
the patch use keystone v3 , in grizzly horizon use keystone v2. On Tue, Jun 25, 2013 at 4:52 PM, Rahul Sharma wrote: > Hi All, > > I have setup multi-node openstack setup using grizzly release and ubuntu > 12.04 distribution. Since there is no support for individual user to change > his/her password, someone has provided a patch for the same. Ref:- > https://review.openstack.org/#/c/23901/31 > > Now I am trying to apply the patch by copying the files to > /usr/share/openstack-dashboard directory. On restarting the Apache service, > I am getting an error. I have attached the logs with the mail. Even if I > revert back the patch, restart apache service and try to access Horizon, > still I get the same error. I have to remove horizon, remove > /usr/share/openstack-dashboard directory and reinstall horizon to get rid > of this error. > > I might be missing some step inbetween to apply this patch to the code. > Can someone help me out in identifying how to apply this patch to the > current installation. I couldn't find any documentation listing how to > apply such patches other than for git repositories. > > Thanks and Regards > Rahul Sharma > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openst...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > -- Shake Chen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
