s, support for
older ansible releases will be dropped
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscri
nk he would
> be a addition to the core team.
>
> What do you folks think?
I think thank you Bob!
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage questions)
Unsu
ve the basic approach
consisting of:
1) create the podman systemd unit
2) delete the docker container
3) start the podman container
could be used to upgrade the Ceph containers as well (via ceph-ansible)
--
Giulio Fidente
GPG K
e squad etherpad as well:
https://etherpad.openstack.org/p/tripleo-edge-squad-status
the edge squad is meeting weekly.
> We are still working on the MVP architecture to clean it up and
discuss comments and questions before moving it to a wiki page. Please
let me know if you would like t
rol Plane (line 74) sessions
can probably be merged into a single one.
I'd be fine with James driving it, I think it'd be fine to discuss the
"control plane updates" issue [1] in that same session.
1.
http://lists.openstack.org/pipermail/openstack-dev/2018-August/133247.html
-
k/tripleo-specs/specs/rocky/split-controlplane.html
2. https://etherpad.openstack.org/p/tripleo-ptg-queens-split-controlplane
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage questio
started helping doing
reviews in other areas.
I am so sure he'll be a great addition to our group that I am not even
looking for comments, just votes :D
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Ma
other services.
I'd like to discuss further this topic at the PTG to gether more
feedback so I added a bullet to the pad with the Stein PTG topics [2].
1. https://blueprints.launchpad.net/tripleo/+spec/split-controlplane
2. h
undesirable
> in some places.
thanks
+1 on A from me as well
we currently cycle through a list of playbooks to execute which can be
given as a Heat parameter ... I suppose we'll need to find a way to make
an ansible variable override the Heat value
--
Giulio Fidente
GPG KEY: 08D733BA
o storage things (Cinder, Glance, Swift, Manila, and
> backends).
>
> Please vote -1/+1,
+1 :D
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
repos for the
> patches related to upgrades (we trust people's judgement for reviews).
>
> As usual, we'll vote!
>
> Thanks everyone for your feedback and thanks Marius for your hard work
> and involvement in the project.
+1
thanks Marius
ookup that is resolved as the "nil" value, not
sure if that is enough to make the default values for a class to apply
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage q
7;t forget much; to stay updated on the progress check
our integration squad status at:
https://etherpad.openstack.org/p/tripleo-integration-squad-status
Thanks
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development
et ... but we might do it non-voting, it's up for
debate
on TripleO side we'd be looking at running scenarios 001 and 004 ...
maybe initially 004 only is good enough as it covers (at least for ceph)
most of what is in 001 as well
can we continue on
a
2. https://blueprints.launchpad.net/tripleo/+spec/nfs-ganesha
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
ee if there are more ways of doing this!
Thanks for the feedback
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subj
to prevent parameter name collisions.
+1 I like very much the idea of parameter_defaults + strictier
namespacing rules
Specifically regarding namespaces, puppet was great but ansible doesn't
seem to be as good (at least to me), in
d
>
> Mathieu Bultel (matbu)
>
> to tripleo-core.
+1 to both with many thanks
long overdue indeed ! :D
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage questions
welcome him
first to tune into radioparadise with the rest of us when joining #tripleo
Feedback is welcomed!
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
here anything you feel
is useful/necessary.
1. https://etherpad.openstack.org/p/tripleo-integration-squad-status
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage questions)
U
sically only a change for a
default value which we'd like to make more production-friendly
1. https://review.openstack.org/#/c/506330/
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usa
hanks!
I think it will also help getting more attention/feedback/reviews on the
various efforts
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev
t;ansible process we'll probably need to ship from THT an heat
query (or ansible task) to be executed by the "outer" ansible to create
the inventory for the inner ansible
I supported the introduction of mistral as an API and would prefer to
have there more informations there versus moving
On 09/20/2017 07:36 PM, James Slagle wrote:
> On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente wrote:
>> On 09/18/2017 05:37 PM, James Slagle wrote:
>>> - The entire sequence and flow is driven via Mistral on the Undercloud
>>> by default. This preserves the API layer an
; rest of the SoftwareDeployment resources in tripleo-heat-templates as
> that will greatly simplify the undercloud container installer. Doing
> so will illustrate using the ephemeral heat-all process as simply a
> means for generating ansible playbooks.
>
> I p
apps using
> OpenStack.
slightly OT but notable mention, scenario001/container is also the one
gating Ceph via ceph-ansible currently :D
... soon to convert scenario004/container as well
--
Giulio Fidente
GPG KEY: 08D733BA
__
hat we can use for
scheduling and discussions.
ack, will do and add links to the etherpad to some LP blueprints
thanks Emilien for setting everything up :D
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing
CI...
agreed which goes back to "nobody looks at the periodic jobs" but
periodic job seems the answer?
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage qu
using
multiple controllers in the upgrade job and drop the standard ovb job
(which doesn't do upgrade) or use it for other purposes?
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not
nments/ssl/tls-endpoints-public-dns.yaml and note how
EndpointMap can resolve to CLOUDNAME or IP_ADDRESS
adding Juan on CC as he did a great work around this and can help further
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenS
probably want to discuss: is this just
so we use ansible to drive the deployment steps or do we want ansible to
replace puppet for the overcloud configuration?
1. https://review.openstack.org/#/c/483929/
--
Giulio Fidente
GPG KEY: 08D733BA
___
On 07/07/2017 07:38 PM, Giulio Fidente wrote:
> On 07/04/2017 08:00 PM, Emilien Macchi wrote:
>> On Wed, Jun 28, 2017 at 9:37 PM, Giulio Fidente wrote:
>>> On 06/28/2017 04:35 PM, Emilien Macchi wrote:
>>>> Hey folks,
>>>>
>>>> Let's st
d some of the ceph-ansible fixes!
for upgrades we should maintain the tasks outside the templates do be
able to do that though, assuming we want users to customize the upgrade
tasks
--
Giulio Fidente
GPG KEY: 08D733BA
__
On 07/10/2017 09:23 PM, James Slagle wrote:
> On Mon, Jul 10, 2017 at 2:54 PM, Giulio Fidente wrote:
>> On 07/10/2017 07:06 PM, James Slagle wrote:
>>> On Mon, Jul 10, 2017 at 11:19 AM, Giulio Fidente
>>> wrote:
>>>> splitstack though requires
On 07/10/2017 07:06 PM, James Slagle wrote:
> On Mon, Jul 10, 2017 at 11:19 AM, Giulio Fidente wrote:
>> On 07/10/2017 03:19 PM, Steven Hardy wrote:
>>> On Fri, Jul 7, 2017 at 6:50 PM, James Slagle wrote:
>>
>> [...]
>>
>>> Yeah, I think the f
;
> Lets sync up about it, but as I mentioned above I'm not yet fully sold
> on a new translation tool, vs just more t-h-t refactoring to enable
> output of data directly consumable via ansible-playbook (which can
> then be
sual, this is an open proposal, any feedback is welcome.
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
the same discussion as what we are
> doing with Ansible, I think it is a big part of the discussion and if
> we want to continue with Heat as the primary orchestration tool in
> TripleO.
I think this is a key question for the conversation we'll have; the
approach in (3) is based on th
On 07/04/2017 08:00 PM, Emilien Macchi wrote:
> On Wed, Jun 28, 2017 at 9:37 PM, Giulio Fidente wrote:
>> On 06/28/2017 04:35 PM, Emilien Macchi wrote:
>>> Hey folks,
>>>
>>> Let's start to prepare the next PTG in Denver.
>>>
>>> Here
!
Flavio is using some of this code for Kubernetes integration as well
1.
https://blueprints.launchpad.net/heat/+spec/mistral-new-resource-type-workflow-execution
2. https://blueprints.launchpad.net/tripleo/+spec/tripleo-ceph-ansible
--
Giulio Fidente
GPG KEY: 08D733BA
_
only?) and pacemaker+containers is
still a work in progress so there aren't easy answers
containers will have access to the host networks though, so the case
for a provider network in the overcloud remains valid
1. https://docs.openstack.org/kilo/networking-guide/scenario_provider_o
vs
On Thu, 2017-04-06 at 13:07 +0200, Ricardo Noriega De Soto wrote:
> Hi owls!
>
> This is something that I've been discussing in the IRC channel but
> still I
> think we should define a consistent way of integrating services which
> support different backends. In this case, I'm refering to BGPVPN a
of providing thorough and thoughtful reviews of
> tripleo-ci patches.
>
> On top of this Attila has greatly increased the communication from the
> tripleo-ci squad as the liason, with weekly summary emails of our
> meetings to this list.
++
where would CI be without you guys :)
te, but it won’t appear on official channels.
>
> Thanks for your passion for this project!
Heidi, thank you.
Can I ask you to also share what are the requirements/goals around the
new logo? That would help me understand *why* and *what* has been
changed in the
l to share the (new?)
requirements as well, so that people can eventually understand those
better too
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: open
here both work.
>
> I think we probably need to do the following:
>
> 1. Convert anything in t-h-t refering to the old hook to the new (seems you
> have this in progress, we need to ensure it all lands before ocata)
was working on this as well today for Ceph
https://review.o
for easy deployment, keep very minimal
> set of mandatory parameters, and rest as optional parameters
> * read introspection data from Ironic DB and Swift-stored blob
>
> I will add these comments as starting point on the spec. We will work
> towards bringing down the dif
y) trigger it before every
deployment
would you be able to join the PTG to help us with the session on the
overcloud settings optimization?
https://etherpad.openstack.org/p/tripleo-ptg-pike
--
Giulio Fidente
GPG KEY
y) trigger it before every
deployment
would you be able to join the PTG to help us with the session on the
overcloud settings optimization?
https://etherpad.openstack.org/p/tripleo-ptg-pike
--
Giulio Fidente
GPG KEY
ately return then.
I'd prefer a different and cleaner approach like you proposed but for me
that's working well for the moment.
ack
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for
hat case?
Alternatively, would an ex-novo Execution resource make more sense?
Or are there different ideas, approaches to the problem?
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usa
On 12/12/2016 02:51 PM, Giulio Fidente wrote:
On 12/09/2016 04:49 PM, Pradeep Kilambi wrote:
Hey Folks:
I would like to get some thoughts on $Subject. This came up when i was
discussing the standalone roles for telemetry. Currently when we deploy
redis in tripleo, its a pacemaker managed
sters, but I am not sure this can happen in Ocata ... yet again, there
shouldn't be in the telemetry roles any dependency on redis itself
if we were to use the cluster mode the only difference would probably be
that the redis_vip will start balancing requests across the nodes
--
Giulio Fiden
+1 !
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.or
solution
because a lot of patches in this repo are not related to OpenStack
versions, which means we would need to backport most of the things
from master.
I'd +1 this idea. It sounds like we could make the scenarios generic
enough to be usable also outside CI? Maybe they can
esses[2]).
I think she will be a valuable addition to the review team
Thanks Dougal and Julie, +1
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev
pefully he does).
+1 ;_)
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openst
On 10/12/2016 02:29 PM, Thiago da Silva wrote:
On 10/12/2016 07:10 AM, Giulio Fidente wrote:
hi,
we introduced support for the deployment of Ceph in the liberty
release so that it could optionally be used as backend for one or more
of Cinder, Glance, Nova and more recently Gnocchi.
We used
against defaulting Nova to Ceph. Feedback?
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://
ight
have a 7th session.
the cross project session with the puppet group is a nice idea indeed,
thanks Emilien
in that context it would be nice to gather some ideas/feedback on the
status of openstack integration scenarios vs tripleo scenarios and see
if we can optimize resources and/or cove
On 09/19/2016 01:25 PM, Steven Hardy wrote:
On Wed, Sep 14, 2016 at 06:32:07PM +0200, Giulio Fidente wrote:
On 09/14/2016 05:59 PM, Giulio Fidente wrote:
On 09/14/2016 02:31 PM, Steven Hardy wrote:
Related to this is the future of all of the per-role customization
interfaces. I'm thi
rfaces (all the folks above have demonstrated solid knowledge of one
or more of our primary interfaces, e.g the Heat or the Mistral layer)
thanks for sharing these ^^
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente
__
O
On 09/14/2016 05:59 PM, Giulio Fidente wrote:
On 09/14/2016 02:31 PM, Steven Hardy wrote:
Related to this is the future of all of the per-role customization
interfaces. I'm thinking these don't really make sense to maintain
long-term now we have the new composable services architectu
e them and move folks towards the
composable services templates instead?
my experience is that the ExtraConfig interfaces have been useful to
provide arbitrary hiera and class includes
I wonder if we could ship by default some roles parsing those parameters?
--
Giulio Fidente
GPG KEY: 08D7
On 08/30/2016 06:40 PM, Giulio Fidente wrote:
Together with Keith we're working on some patches to integrate (via
puppet-ceph) the deployment of Ceph RGW in TripleO as a composable
service which can optionally replace SwiftProxy
Changes are tracked via blueprint at:
On 09/01/2016 02:11 AM, Giulio Fidente wrote:
On 08/30/2016 10:50 PM, Steven Hardy wrote:
On Tue, Aug 30, 2016 at 03:25:30PM -0400, Emilien Macchi wrote:
Here's my 2 cents:
The patch in puppet-ceph has been here for long time now and it still
doesn't work (recent update of today, p
o rework of the composable services interface will be needed, the tht
submission is, in addition to adding the new service template, adding an
output to the endpoint map for the new service, the puppet submission is
adding a new role
https://review.openstack.org/#/c/289027/
--
Giu
o formally request an FFE for this feature.
Thanks for consideration, feedback, help and reviews :)
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
not logging, maybe
defaulting it to stdout but skip if it is None?
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.ope
teresting to have undercloud/ha (point 7)
fwiw, I'd like to try this out myself before the summit to get a better
picture.
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente
__
OpenStack Development
acked by Ceph for HA job), set some routing and ping it (in network
isolation!)
1.
https://github.com/openstack-infra/tripleo-ci/blob/master/templates/tenantvm_floatingip.yaml
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente
__
service by default for newton as well
1. https://review.openstack.org/#/c/357729
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstac
a
"full" overcloud could work?
there is a similar requirement for testing 'competing' services, like
swift and ceph/rgw which we're about to merge ... but applies to other
things, like the neutron plugi
On 08/04/2016 01:26 PM, Christian Schwede wrote:
On 04.08.16 10:27, Giulio Fidente wrote:
On 08/02/2016 09:36 PM, Christian Schwede wrote:
Hello everyone,
thanks Christian,
I'd like to improve the Swift deployments done by TripleO. There are a
few problems today when deployed wit
t further
customizations
what do you think?
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
file was overriding the setting anyway and
we got tricked into thinking the change was working while it wasn't
so +1 from me on option number 2
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente
__
OpenStack Developme
n the initial
submission should the ceph migration reveal to be problematic
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev
rvice templates. I'll try to put up a
WIP unless people has better ideas.
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
I'll post an update as soon as I get it to work
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstac
me of the
upcoming features like composable services, etc.
If you agree please +1. If there is no negative feedback I'll add him
next Monday.
+1 !
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing Lis
of things.
I'd like to propose we add him to our core team (probably long overdue
now too).
+2
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstac
estly are a bit confusing and even lack
documentation about quite some features for end users.
Maybe we can start some minor restructuring of the docs, splitting them
into a 'quickstart' guide and a 'feature-complete' guide and ask people
to submit together with a feature the
athered from environments-file?
5. make sure not to mangle the file paths; these can be absolute or
relative to the templates location
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing Li
s: users won't
need to update their environment files in case the parameter is moved
from top-level into a specific nested stack so I'm inclined to prefer
this. Are there reasons not to?
--
Giulio Fidente
GPG KEY: 08D733BA
On 11/10/2015 04:47 PM, Dmitry Tantsur wrote:
On 11/10/2015 04:37 PM, Giulio Fidente wrote:
On 11/10/2015 04:16 PM, Dmitry Tantsur wrote:
On 11/10/2015 04:08 PM, Tzu-Mainn Chen wrote:
Hi all,
At the last IRC meeting it was agreed that the new TripleO REST API
should forgo the Tuskar name
ython-tripleoclient)
are meant to consume the shared code (business logic) from
tripleo-common, then I think it makes sense to keep each in its own repo
... so that we avoid renaming tripleo-common as well
--
Giulio Fidente
GPG KEY: 08D733BA | IRC: gi
ce of implementing the bot/automation pieces.
/me doesn't have experience but would think about the bot as a very
'stupid' tool rather than an intelligent one; stopping the backports
seems generally safer than an automated merge which breaks things out of
immediate sight
-
On 05/08/2015 05:41 PM, James Slagle wrote:
On Thu, May 7, 2015 at 5:46 PM, Giulio Fidente wrote:
On 05/07/2015 07:35 PM, Dan Prince wrote:
On Thu, 2015-05-07 at 17:36 +0200, Giulio Fidente wrote:
On 05/07/2015 03:31 PM, Dan Prince wrote:
On Thu, 2015-05-07 at 11:22 +0200, Giulio Fidente
e with a different base image)? Sure there is some complexity but
we won't have to rethink about HA for the undercloud for example nor to
duplicate the templates/manifests for it.
--
Giulio Fidente
GPG KEY: 08D733BA
_
On 05/07/2015 07:35 PM, Dan Prince wrote:
On Thu, 2015-05-07 at 17:36 +0200, Giulio Fidente wrote:
On 05/07/2015 03:31 PM, Dan Prince wrote:
On Thu, 2015-05-07 at 11:22 +0200, Giulio Fidente wrote:
[...]
on the other hand, we can very well get rid of the ifs today by
deploying *with
On 05/07/2015 05:36 PM, Giulio Fidente wrote:
On 05/07/2015 03:31 PM, Dan Prince wrote:
On Thu, 2015-05-07 at 11:22 +0200, Giulio Fidente wrote:
[...]
and there are quite a lot of similar examples, the change from marios as
well, ended up duplicating lots of code:
https
On 05/07/2015 03:31 PM, Dan Prince wrote:
On Thu, 2015-05-07 at 11:22 +0200, Giulio Fidente wrote:
[...]
I think the change is good, I am assuming we don't want the shared parts
to get duplicated into the two .pp though.
So again. Duplicating the puppet class includes doesn't bot
.pp to have a lot of duplicated
data, making them not better than one with the ifs IMHO
we should probably move out of the existing .pp the duplicated parts
first (see my other email on the matter)
--
Giulio Fidente
GPG KEY: 08D733BA
erentiated top-level template maybe? Something else?
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Hi,
the Heat/Puppet implementation of the Overcloud deployment seems to be
surpassing in features the Heat/Elements implementation.
The changes for Ceph are an example, the Puppet based version is already
adding features which don't have they counterpart into Elements based.
Recently we sta
preferences in
the etherpad, so we can start to see if there's a larger group of
people we can accommodate at the alternate meeting time.
I don't think we need the alternate slot.
I added myself in the etherpad to the list of people who can stick with
the single "primary" t
r
config management tool is deployed)
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.o
onally, while I tried to join this conversation in the past, I am
still unsure whether for tripleo a stable/master approach would work
better or not than a synchronized release cadence
--
Giulio Fidente
GPG KEY: 08D733BA
k-infra/tripleo-ci/blob/master/docs/wanted_ci_jobs.csv
--
Giulio Fidente
GPG KEY: 08D733BA
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://
Can I suggest an alternative data gathering method, I've put each hour
in a week in a poll, for each slot you have 3 options
I think it is great, but would be even better if we could trim it to
just a *single* day and once we agreed on the timeframe, we decide on
the day as that probably w
1 - 100 of 130 matches
Mail list logo
