+1
On Thu, Jul 16, 2015 at 1:47 AM, Oleg Bondarev
wrote:
> +1
>
> On Thu, Jul 16, 2015 at 2:04 AM, Brian Haley wrote:
>
>> +1
>>
>>
>> On 07/15/2015 02:47 PM, Carl Baldwin wrote:
>>
>>> As the Neutron L3 Lieutenant along with Kevin Benton for control
>>> plane, and Assaf Muller for testing, I w
Yes, Anita. We are seeking the alternatives to fix it and hope the CIs can be
recovered very soon.
Also please allow me to explain a little bit, we shut down the service without
any email notification, but update the wiki
(https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-PCI-CI) only acc
Doug Hellmann wrote:
> Excerpts from Anne Gentle's message of 2015-07-16 08:14:54 -0500:
>> On Thu, Jul 16, 2015 at 6:58 AM, Doug Hellmann
>> wrote:
>>
>>> Excerpts from Andreas Jaeger's message of 2015-07-16 08:11:48 +0200:
Doug,
I'm missing openstackdocstheme and openstack-doc-too
Aha! Thanks so much for pointing that out. Although actually it's a reminder,
and I should have known that already, as I now remember your recent thread
about this.
So, 100% understood now that flavors aren't intended for networks.
I hope that the metaplugin removal change might land quickly
On 07/17/2015 10:02 AM, Thierry Carrez wrote:
Doug Hellmann wrote:
Excerpts from Anne Gentle's message of 2015-07-16 08:14:54 -0500:
On Thu, Jul 16, 2015 at 6:58 AM, Doug Hellmann
wrote:
Excerpts from Andreas Jaeger's message of 2015-07-16 08:11:48 +0200:
Doug,
I'm missing openstackdocsthe
Le 16/07/2015 22:28, Thomas Goirand a écrit :
IMO, we should, for the Liberty release, get rid of:
- suds & suds-jurko
suds was replaced with suds-jurko (in oslo.vmware, cinder, nova): I
kicked suds off of global requirements.
- memcached (in the favor of pymemcache)
As I wrote, I may for
On 07/17/2015 10:19 AM, Andreas Jaeger wrote:
[...]
I agree, we treat them as deliverables, so let me setup launchpad
projects for these...
Created,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
G
Hello!
Please give me opinion in terms to be a valuable function for OpenStack
Community.
We believe that we need a mechanism to easily manage the resources available to
the each tenant.
In some case, we want to allow only the specific tenant to use the specific
resources.
We think the two ar
Hello everyone,
Based on the conversation we had during last meeting I went ahead and
created an
ini_setting provider[1] that will act as a proxy between our provider
and the
upstream one, this way we don't have to fork, only overload the method
we want.
The second step towards parameter defaul
Le 17/07/2015 10:42, Kenji Ishii a écrit :
Hello!
Please give me opinion in terms to be a valuable function for OpenStack
Community.
We believe that we need a mechanism to easily manage the resources available to
the each tenant.
In some case, we want to allow only the specific tenant to use
Hi,
I think that we should provide a separate script that will fetch the
upstream modules into fuel-library/deployment/puppet/ directory. It will
allow us to have everything in a single place and use this script in ISO
build process and CI jobs.
Regards,
Alex
On Thu, Jul 16, 2015 at 11:17 PM, Al
michael mccune wrote:
> hey all,
>
> we have 4 API Guidelines that are ready for final review.
>
> 1. Add generic name of each project for terms
> https://review.openstack.org/#/c/196918/
>
> 2. Add new guideline for HTTP Headers
> https://review.openstack.org/#/c/186526/
>
> 3. Adds guidance o
Thanks for the heads up Jamie, I'll try to take a look.
-Stuart
Glancers,
A while ago I wrote an email outlining a couple of ways we could support
keystone v3 authentication when using swift as a backend for glance_store. In
the long term it would be best to transition swiftclient to use s
Thomas Goirand wrote:
> IMO, we should, for the Liberty release, get rid of:
> - suds & suds-jurko
> - memcached (in the favor of pymemcache)
> - mysqldb (this has been discussed at large already)
> - cliff-tablib and tablib (not ported to Py3, used only for testing)
I feel like there is an opport
On 07/16/2015 06:06 PM, Sean M. Collins wrote:
> On Thu, Jul 16, 2015 at 01:23:29PM PDT, Mathieu Gagné wrote:
>> So it looks like there is a missing part in this feature. There should
>> be a way to "hide" this information if the instance does not require to
>> configure vlan interfaces to make net
Sounds like a great idea Thierry! Any concrete deliverables you have
in mind for this group?
thanks,
dims
On Fri, Jul 17, 2015 at 6:07 AM, Thierry Carrez wrote:
> Thomas Goirand wrote:
>> IMO, we should, for the Liberty release, get rid of:
>> - suds & suds-jurko
>> - memcached (in the favor of
On Thu, Jul 16 2015, Angus Salkeld wrote:
Hi Angus,
> I just saw this, and I am concerned this is going to kill Heat's gate (and
> user's templates).
>
> Will this be hidden within the client so that as long as we have aodh
> enabled in our gate's devstack
> this will just work?
As Gordon said,
Hi,
We are close to having a voting py34 gate on all OpenStack libraries and
applications. I just made the py34 gate voting for the 5 following projects:
* keystone
* heat
* glance_store: Glance library (py34 is already voting in Glance)
* os-brick: Cinder library (py34 is already voting in Ci
Hey Alex,
On Jul 17, 2015 4:32 AM, "Aleksandr Didenko" wrote:
>
> Hi,
>
> I think that we should provide a separate script that will fetch the
upstream modules into fuel-library/deployment/puppet/ directory. It will
allow us to have everything in a single place and use this script in ISO
build pr
Davanum Srinivas wrote:
> Sounds like a great idea Thierry! Any concrete deliverables you have
> in mind for this group?
I don't think that team would use a specific repository. More like agree
on a set of objectives to reach in a given cycle, like the list Thomas
came up with. If one ends up bein
I believe build_repo function is the best way to do this [0]. So for
fuel-library we'll need to run a shell script right from the repo before
'touch $$@'. We can make it either conditional ( test -f
./path/additional_build_script.sh && bash ./path/additional_build_script.sh
) or as additional param
Thank you for reply!
> Not sure I fully understand but AggregateMultiTenancyIsolation filter
> already partially does the job (with a certain number of pitfalls, one being
> addressed in https://review.openstack.org/#/c/195783/ )
I understand that nova already has function to isolate resources fo
On 17 July 2015 at 11:23, Sean Dague wrote:
> On 07/16/2015 06:06 PM, Sean M. Collins wrote:
>> On Thu, Jul 16, 2015 at 01:23:29PM PDT, Mathieu Gagné wrote:
>>> So it looks like there is a missing part in this feature. There should
>>> be a way to "hide" this information if the instance does not r
On 17 July 2015 at 23:32, Victor Stinner wrote:
> Hi,
> https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1367907
>
> The bug was fixed in Python 3.4 in May 2014 and was reported to Ubuntu in
> September 2014.
I've just queried and its apparently in review-wait in the Ubuntu
trusty upload
Thierry,
+1 from me. We could just use a wiki to track work or upstream
PR/reviews for now.
-- dims
On Fri, Jul 17, 2015 at 7:40 AM, Thierry Carrez wrote:
> Davanum Srinivas wrote:
>> Sounds like a great idea Thierry! Any concrete deliverables you have
>> in mind for this group?
>
> I don't thi
Alex,
Gathering upstream modules certainly should be implemented as a separate
script so as to make it possible to use it wherever we need this (tests,
builds, etc.) According to builds there are two things
1) We have so called "perestroika" package build system (Dmitry Burmistrov
is a main contr
> On Jul 17, 2015, at 04:36, Victor Stinner wrote:
>
> Le 16/07/2015 22:28, Thomas Goirand a écrit :
>> IMO, we should, for the Liberty release, get rid of:
>> - suds & suds-jurko
>
> suds was replaced with suds-jurko (in oslo.vmware, cinder, nova): I kicked
> suds off of global requirements.
On Fri, Jul 17, 2015 at 3:02 AM, Thierry Carrez
wrote:
> Doug Hellmann wrote:
> > Excerpts from Anne Gentle's message of 2015-07-16 08:14:54 -0500:
> >> On Thu, Jul 16, 2015 at 6:58 AM, Doug Hellmann
> >> wrote:
> >>
> >>> Excerpts from Andreas Jaeger's message of 2015-07-16 08:11:48 +0200:
> >>
Hi,
as we decided on the recent Fuel weekly IRC meeting, we need to align LP
fuel-* groups with our teams and bug confirmation queues/duties. We decided
to start with fuel-astute [0] and fuel-provsioning [1] LP groups that have
2 members each. So from now on please assign bugs about provisioning a
Hi,
Alex vote +1 to use astute tag as well to get possibility identify issues
related to astute in the most easy way.
Regards,
Tanya
On Fri, Jul 17, 2015 at 3:59 PM, Aleksandr Didenko
wrote:
> Hi,
>
> as we decided on the recent Fuel weekly IRC meeting, we need to align LP
> fuel-* groups with
Hello guys,
> Update 'make iso' scripts:
> * Make them use 'r10k' (or other tool) to download upstream modules based
> on 'Puppetfile'
I foreseen holywars with our Build team. AFAIK they are deeply
concerned about Internet access during ISO build process. Hence,
they'll propose to package upst
+1
On Fri, Jul 17, 2015 at 5:43 AM, Dmitry Borodaenko
wrote:
> +1
>
> On Thu, Jul 16, 2015 at 8:57 AM Sergii Golovatiuk
> wrote:
>>
>> +1
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Thu, Jul 16, 2015 at 10:20 AM, Vladimir Sharshov
>> wrote:
>>>
>>>
+1
On Fri, Jul 17, 2015 at 4:20 PM, Igor Kalnitsky
wrote:
> +1
>
> On Fri, Jul 17, 2015 at 5:43 AM, Dmitry Borodaenko
> wrote:
> > +1
> >
> > On Thu, Jul 16, 2015 at 8:57 AM Sergii Golovatiuk <
> sgolovat...@mirantis.com>
> > wrote:
> >>
> >> +1
> >>
> >> --
> >> Best regards,
> >> Sergii Golov
Hello,
Here's my +2 on this. :)
BTW, any chance we can somehow to reduce spam emails when some bug was
assigned to another team? For instance, I see email notifications when
bug's assigned to fuel-library.
Thanks,
Igor
On Fri, Jul 17, 2015 at 4:16 PM, Tatyana Leontovich
wrote:
> Hi,
>
> Alex v
Matt,
Thanks for noting this. My understanding of the problem is that we should
put openstack.yaml into a separate package build from fuel-web repository.
When a user installs fuel-upgrade package it requires openstack.yaml
package of necessary version to be also installed.
Another idea here is t
On 07/17/2015 05:50 AM, Thierry Carrez wrote:
michael mccune wrote:
hey all,
we have 4 API Guidelines that are ready for final review.
1. Add generic name of each project for terms
https://review.openstack.org/#/c/196918/
2. Add new guideline for HTTP Headers
https://review.openstack.org/#/c/
Madhuri,
Alee is in EST timezone (gmt-5 IIRC). Alee will help you get barbican rolling.
Can you two folks set up a time to chat on irc on Monday or tuesday?
Thanks
-steve
__
OpenStack Development Mailing List (not for us
Sounds good to me,
+1
I know that some of the oslo core (I've done a little) and others
(victor does a-lot of it) have been taking over this duty already but
some kind of miniature group that has this a main goal would be cool to.
-Josh
Davanum Srinivas wrote:
Thierry,
+1 from me. We coul
Victor Stinner wrote:
Le 16/07/2015 22:28, Thomas Goirand a écrit :
IMO, we should, for the Liberty release, get rid of:
- suds & suds-jurko
suds was replaced with suds-jurko (in oslo.vmware, cinder, nova): I
kicked suds off of global requirements.
- memcached (in the favor of pymemcache)
Morgan Fainberg wrote:
On Jul 17, 2015, at 04:36, Victor Stinner wrote:
Le 16/07/2015 22:28, Thomas Goirand a écrit :
IMO, we should, for the Liberty release, get rid of:
- suds& suds-jurko
suds was replaced with suds-jurko (in oslo.vmware, cinder, nova): I kicked suds
off of global requi
Hey Vladimir,
On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> Alex,
>
> Gathering upstream modules certainly should be implemented as a separate
> script so as to make it possible to use it wherever we need this (tests,
> builds, etc.) According to builds
On Thu, Jul 16, 2015 at 8:39 PM, Sean M. Collins wrote:
> Hi Cathy,
>
> You recently merged the following patch, by +2'ing and then
> Workflow+1'ing it, without allowing reviewers the chance to look at the
> changes between the patchset where there were -1's and the newer
> patchsets.
>
> https:/
Hello all,
I would like to nominate Matt Kassawara (IRC: sam-i-am) to the OpenStack
Ansible deployment core team. Matt has been instrumental in building out our
current install and use documentation[0], he is just about always in the
community channel(s) helping folks, is a great technical reso
Hi
Role assignment inheritance has been an extension in Keystone for a number of
cycle. With the introduction of project hierarchies (which also support
assignment inheritance), we’d like to move inheritance into core.
At the same time as the move to core, we’d like to modify the way inheritan
I am +1. Matt's been a huge help with his contributions to our documentation
and guides, both in actual commits and reviews.
From: Kevin Carter
Sent: Friday, July 17, 2015 11:14 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [
On the top of that the co-authors should NOT be voting +2 on their own patch!
Edgar
From: Kyle Mestery
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Friday, July 17, 2015 at 8:13 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [o
On 07/17/2015 11:19 AM, Nolan Brubaker wrote:
> Matt ... is just about always in the community channel(s) helping folks, is a
> great technical resource for all things networking / OpenStack,
I heartly agree. I haven't looked at the ansible reviews so can't speak
to that, but I do acknowledge the
Thanks all.
>From this moment Vladimir Kozhukalov is a core-reviewer of
fuel-nailgun-agent.
On Fri, Jul 17, 2015 at 4:25 PM, Tatyana Leontovich <
tleontov...@mirantis.com> wrote:
> +1
>
> On Fri, Jul 17, 2015 at 4:20 PM, Igor Kalnitsky
> wrote:
>
>> +1
>>
>> On Fri, Jul 17, 2015 at 5:43 AM, Dmi
Hey Yanis,
On Fri, Jul 17, 2015 at 3:56 AM, Yanis Guenane wrote:
> Hello everyone,
>
> Based on the conversation we had during last meeting I went ahead and
> created an
> ini_setting provider[1] that will act as a proxy between our provider
> and the
> upstream one, this way we don't have to f
On Fri, Jul 17, 2015 at 01:06:46PM +0100, John Garbutt wrote:
> On 17 July 2015 at 11:23, Sean Dague wrote:
> > On 07/16/2015 06:06 PM, Sean M. Collins wrote:
> >> On Thu, Jul 16, 2015 at 01:23:29PM PDT, Mathieu Gagné wrote:
> >>> So it looks like there is a missing part in this feature. There sho
Yes the day is still Tuesday. Sorry that wasn't clear.
Tim
On Tue, Jul 14, 2015 at 7:30 PM Masahito MUROI
wrote:
> I'm happy to see that.
>
> btw, is the day on Tuesday?
>
> best regard,
> masa
>
> On 2015/07/15 9:52, Zhou, Zhenzan wrote:
> > Glad to see this change.
> > Thanks for the support
Hi guys!
Currently Murano holds the *#murano* IRC channel.
But all openstack projects have the openstack- prefix in their channel’s
name.
So I have a question: should we move to *#openstack-murano*?
I think it’s a good idea, since it’s more obvious to go to*
#openstack-murano* if one needs help
Hi Folks,
In my CI I see the following tempest tests failure for a past couple of
days.
-
tempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario
[361.274316s] ... FAILED
-
tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_p
Hi Mike,
We are taking it as a high priority.
We have moved all CIs to sand-box for making sure that they do not generate
spam.
We will move these CIs to cinder patches ASAP and will update the wiki page
of third party CI.
Please let me know if you have any questions.
Regards
Nikesh
On Wed, Jul
Hi, Kate!
So I have a question: should we move to #openstack-murano?
I think it’s a good idea, since it’s more obvious to go to #openstack-murano if
one needs help with murano.
I like this idea. Strong +1 to it.
--
Victor Ryzhenkin
Junior QA Engeneer
freerunner on #freenode
Включено 17 июля
michael mccune wrote:
> On 07/17/2015 05:50 AM, Thierry Carrez wrote:
>> Note that we won't be having a cross-project meeting on July 21st, so
>> these won't get the opportunity to get discussed in that forum. So you
>> might want to delay that final approval for an extra week...
>>
>> Your call.
>
Joshua Harlow wrote:
> Sounds good to me,
>
> +1
>
> I know that some of the oslo core (I've done a little) and others
> (victor does a-lot of it) have been taking over this duty already but
> some kind of miniature group that has this a main goal would be cool to.
And now for the hardest part..
+1, Kate.
Lee
--
Lee Calcote
Director, Software Engineering | Cloud Systems and Solutions
Seagate Technology | 10200 S. De Anza Blvd., Cupertino, CA 95014
(W) 408-658-1861 (C) 512-810-2771 (T) @lcalcote
> On Jul 17, 2015, at 11:26 AM, Victor Ryzhenkin
> wrote:
>
> Hi, Kate!
>
>> So I have a
Hi, Adrian, Jay and all,
There could be a much longer version of this, but let me try to explain in a
minimalist way.
Bay currently has two modes: VM-based, BM-based. In both cases, Bay helps to
isolate different tenants' containers. In other words, bay is single-tenancy.
For BM-based bay, t
All,
Does anyone have insight into Google's plans for contributing to containers
within OpenStack?
http://googlecloudplatform.blogspot.tw/2015/07/Containers-Private-Cloud-Google-Sponsors-OpenStack-Foundation.html
Regards,
Daneyon Hansen
__
Check out my comments on the review. Only Neutron knows whether or not an
instance needs to do manual tagging based on the plugin/driver loaded.
For example, Ironic/bare metal ports can be bound by neutron with a correct
driver so they shouldn't get the VLAN information at the instance level in
th
(adding [ironic] since baremetal use cases are involved)
On 2015-07-17 11:51 AM, Jim Rollenhagen wrote:
> On Fri, Jul 17, 2015 at 01:06:46PM +0100, John Garbutt wrote:
>> On 17 July 2015 at 11:23, Sean Dague wrote:
>>> On 07/16/2015 06:06 PM, Sean M. Collins wrote:
On Thu, Jul 16, 2015 at 01
Well we already have a debtcollector[1] library,
It serves similar purposes for actively maintained libraries (not
dead/abandoned ones),
So how about a group named 'the debtcollectors'
[1] http://docs.openstack.org/developer/debtcollector/
Thierry Carrez wrote:
Joshua Harlow wrote:
Sounds
On Fri, Jul 17, 2015 at 10:56:36AM -0600, Kevin Benton wrote:
> Check out my comments on the review. Only Neutron knows whether or not an
> instance needs to do manual tagging based on the plugin/driver loaded.
>
> For example, Ironic/bare metal ports can be bound by neutron with a correct
> drive
Hi Sean,
I was on IRC Infra channel yesterday getting guidance about the merge.
I have replied to all the other comments on the new version 12 and addressed
them in the latest updated version, but I did not spot yours since yours is
towards the end of the spec and Louis, not I, replied to your c
On Thu, Jul 16, 2015 at 08:59:19PM PDT, Richard Woo wrote:
> Sean, I agreed with you. But after I read Yan's user case. I think the
> FWaaS API may become too complex for that case.
Can you expand on this? I'd like to know more since if the FwaaS API is
too complex we need to take steps to improve
On Fri, Jul 17, 2015 at 10:43:37AM -0700, Jim Rollenhagen wrote:
> On Fri, Jul 17, 2015 at 10:56:36AM -0600, Kevin Benton wrote:
> > Check out my comments on the review. Only Neutron knows whether or not an
> > instance needs to do manual tagging based on the plugin/driver loaded.
> >
> > For exam
Hi,
As anyone wondered if it could be possible/feasible to have an unified
interface where all instances (or resources) are listed in one single
page for all regions available in the catalog?
What would be the challenges to make it happen? (so you don't have to
toggle between regions)
--
Mathie
Matt does add value, and I definitely don't want to imply that what he does
isn't great work or that it isn't helpful to the project, however its hard
to +1 a Core reviewer who has 1 review in the liberty timeframe. Since one
of the primary purposes of core reviewers is to actively review code it
d
I personally think having JS code generated from Django template is not
necessary better than having JS globals. Actually I finding it is more
problematic and keep causing issues:
* app.module.js has to be manually collected and being placed before some
Django template generated JS code:
h
Alex,
Great that you did this. Now I think I can prepare fuel-main patch to
invoke this script right before building fuel-library package. I'll add you
to review it. Is it ok if I do this monday morning?
Vladimir Kozhukalov
On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz wrote:
> Hey Vladimir,
>
On 07/17/2015 12:33 PM, Thierry Carrez wrote:
michael mccune wrote:
On 07/17/2015 05:50 AM, Thierry Carrez wrote:
Note that we won't be having a cross-project meeting on July 21st, so
these won't get the opportunity to get discussed in that forum. So you
might want to delay that final approval
Josh,
How about a "defibrillators" :) or a "phoenix" reference!
but seriously, we probably need some official-ish name like "Community
outreach" or "Ecosystem curators"..
Thanks,
dims
On Fri, Jul 17, 2015 at 1:24 PM, Joshua Harlow wrote:
> Well we already have a debtcollector[1] library,
>
>
It is certainly possible. And a common request. I have it as a priority to
look into during the latter half of Liberty.
There are two factors that prompted the current model. Taking the example
of the instances page (as it exists today).
1) The resulting page would be making 6 API calls to 3 serv
Hey Vladimir,
So I've been playing with it at the moment because I think the better place
to do the script execution is as part of the build process controlled by
the fuel-library7.0 spec file[0]. It seems to be a valid way to do it (and
would work for our CI jobs to) but the issue i'm running in
+1 from me. First time I join to this channel before #murano.
Nikolay Starodubtsev
Software Engineer
Mirantis Inc.
Skype: dark_harlequine1
2015-07-17 19:33 GMT+03:00 Lee Calcote :
> +1, Kate.
>
> Lee
> --
> Lee Calcote
> Director, Software Engineering | Cloud Systems and Solutions
> Seagat
On 07/16/2015 04:31 PM, michael mccune wrote:
i will also likely be rewriting the spec to encompass these changes if i
can get them working locally.
just wanted to follow up before i rewrite the spec.
i think the most sensible approach at this point is to store an auth
plugin object in our co
> which requires VLAN info to be pushed to the host. I keep hearing "bare
metal will never need to know about VLANs" so I want to quash that ASAP.
That's leaking implementation details though if the bare metal host only
needs to be on one network. It also creates a security risk if the bare
metal
On Fri, Jul 17, 2015 at 12:24 PM Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> Alex,
>
> Great that you did this. Now I think I can prepare fuel-main patch to
> invoke this script right before building fuel-library package. I'll add you
> to review it. Is it ok if I do this monday morni
On 7/15/2015 5:38 PM, melanie witt wrote:
Hi Everyone,
Recently I have started reviewing the patch series about nested quotas in nova [1] and
I'm having trouble understanding where we currently are with identity v3 support in nova.
From what I read in a semi recent proposal [2] I think thing
Hey All,
I've figured it out without having to modify the fuel-main build code. I've
updated the fuel-library spec with a build action that invokes the script
to pull down external modules. Please take some time to review the two
reviews out there for this change to see if there are any issues wi
On 7/17/2015 6:32 AM, Victor Stinner wrote:
Hi,
We are close to having a voting py34 gate on all OpenStack libraries and
applications. I just made the py34 gate voting for the 5 following
projects:
* keystone
* heat
* glance_store: Glance library (py34 is already voting in Glance)
* os-brick:
Igor,
There shouldn't be any holywars as we are going to add our tests to Puppet
manifests projects. We'll be able to resolve fast enough. In case of
problems we can stick librarian to particular commit in upstream repo.
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
On Fri, J
Heat does seem to use #heat though. But I have to agree, that most os OpenStack
projects use #openstack-something
I do not have a strong opinion about the idea, but I’m pretty sure nobody came
to #openstack-murano and asked anything there. People usually do not ask
questions in empty channels
Fantastic, do we have some way to validate that the module was pulled in
properly as part of fuel-library CI?
On Fri, Jul 17, 2015 at 2:48 PM Alex Schultz wrote:
> Hey All,
>
> I've figured it out without having to modify the fuel-main build code.
> I've updated the fuel-library spec with a buil
On 17 Jul 2015 1:38 pm, "Morgan Fainberg" wrote:
>
> > On Jul 17, 2015, at 04:36, Victor Stinner wrote:
> > FYI some colleagues just forked python-ldap in
https://github.com/pyldap/pyldap/ to add Python 3 support. Stay tuned ;-)
> >
>
> I highly recommend contributing to the ldap3 project instea
On 18 Jul 2015 6:29 am, michael mccune wrote:
>
> On 07/16/2015 04:31 PM, michael mccune wrote:
> > i will also likely be rewriting the spec to encompass these changes if i
> > can get them working locally.
>
> just wanted to follow up before i rewrite the spec.
>
> i think the most sensible
Not until we start using it then any ci that tests with that module will
validate the modules inclusion. You can check the output of the jobs as we
are printing what modules are managed by librarian.
-Alex
On Jul 17, 2015 6:17 PM, "Andrew Woodward" wrote:
> Fantastic, do we have some way to vali
We started the day with a mock 1.1.4 release breaking unit tests for a
few projects (nova, cinder, ironic at least).
The nova blocker was tracked with bug 1475661.
We got a g-r change up to block mock!=1.1.4 but that didn't fix the
issue because oslo.versionedobjects pulls mock in before pip p
On 7/17/2015 7:51 PM, Matt Riedemann wrote:
We started the day with a mock 1.1.4 release breaking unit tests for a
few projects (nova, cinder, ironic at least).
The nova blocker was tracked with bug 1475661.
We got a g-r change up to block mock!=1.1.4 but that didn't fix the
issue because osl
On Fri, Jul 17, 2015 at 8:52 PM, Julien Danjou wrote:
> On Thu, Jul 16 2015, Angus Salkeld wrote:
>
> Hi Angus,
>
> > I just saw this, and I am concerned this is going to kill Heat's gate
> (and
> > user's templates).
> >
> > Will this be hidden within the client so that as long as we have aodh
>
One of the concerns raised by TC in response to the proposal to add Fuel to
OpenStack Projects [0] is the fact that fuel-library includes copies of
upstream Puppet modules, most importantly from OpenStack Puppet [1].
[0] https://review.openstack.org/199232
[1] https://lwn.net/Articles/648331/
I
To be clear Matt has been active an active reviewer. The previous reference
link simply showed commits owned by him which also pertained to our project.
Here is a complete list of changes that he's reviewed[0][1] in the OSAD project.
--
Kevin Carter
IRC: cloudnull
[0]
https://review.openstac
93 matches
Mail list logo