Started a new thread so that we don't hijack the older thread.
as
Andrew, will you work on it in 6.0? What are remaining items there? Also,
it might affect our tests - simple mode runs faster so we use it for smoke
ISO test. Anastasia, please confirm that we can switch smoke to
Mike,
I've started a separate thread titled 'removing single mode' so that we
don't thread jack the ssl conversation.
On Thu, Aug 21, 2014 at 12:27 PM, David Easter deas...@mirantis.com wrote:
Hi Adam,
Just to clarify the subtlety of this change - you can still install a
single
--
Andrew Woodward
Mirantis
On Thu, Dec 12, 2013 at 6:31 AM, Mike Scherbakov
mscherba...@mirantis.comwrote:
Folks,
Most of you by now have heard of Fuel, which we’ve been working on as a
related OpenStack project for a period of time -
https://github.com/stackforge/fuel-mainsee https
All,
I'd like to ask the core reviewers to review both patch sets again since
they are now basically the same. I'd like to see either merged so the bug
cane closed and improve cinder (and ceph). We can simply determine
preference by votes.
Thanks
Andrew Woodward
Mirantis
On Fri, Dec 6, 2013
From my some testing I did a couple of months ago, we decided to move to
XFS to avoid the issue
I was poking around with after my file system inadvertently filled and
found that in ex3/4 all of the inodes in the file system have to be zeroed
prior to mkfs completing (unless the kernel is above
Hi Kevein
the development setup docs are at
http://docs.mirantis.com/fuel-dev/develop/env.html (although they could be
slightly stale). The gist of it is that for nailgun, you need to install
all of the packages in nailgun/requirements.txt (pip install -r
requirements.txt) this should set you up
I would think that the intent of the tests would be to use the /opt
partition that was attached to the instance. I would think that we should
be able to configure the resources to use /opt instead. or hack /var to be
inside /opt.
Either way, growing the root volume would likely be the most
Hi, I'm writing to call for some core-reviewers to give any eye to
some rbd related reviews that are open.
https://review.openstack.org/#/c/59149/
^parent https://review.openstack.org/#/c/59148/
^^parent https://review.openstack.org/#/c/33409/
Thanks,
Andrew W.
Mirantis.
I'd Like to request A FFE for the remaining patches in the Ephemeral
RBD image support chain
https://review.openstack.org/#/c/59148/
https://review.openstack.org/#/c/59149/
are still open after their dependency
https://review.openstack.org/#/c/33409/ was merged.
These should be low risk as:
1.
...@redhat.com wrote:
On 03/06/2014 03:20 AM, Andrew Woodward wrote:
I'd Like to request A FFE for the remaining patches in the Ephemeral
RBD image support chain
https://review.openstack.org/#/c/59148/
https://review.openstack.org/#/c/59149/
are still open after their dependency
https
is
effectively useless and I'd love to see that second sponsor so us Ceph
users don't have to use hand patched nova for another release.
On Thu, Mar 6, 2014 at 3:30 PM, Matt Riedemann
mrie...@linux.vnet.ibm.com wrote:
On 3/6/2014 2:20 AM, Andrew Woodward wrote:
I'd Like to request A FFE for the remaining
s...@dague.net wrote:
On 03/07/2014 11:16 AM, Russell Bryant wrote:
On 03/07/2014 04:19 AM, Daniel P. Berrange wrote:
On Thu, Mar 06, 2014 at 12:20:21AM -0800, Andrew Woodward wrote:
I'd Like to request A FFE for the remaining patches in the
Ephemeral
RBD image support chain
https
I disagree with the new dependency graph here, I don't think its reasonable
continue to have the Ephemeral RBD patch behind both glance v2 support and
image-multiple-location. Given the time that this has been in flight, we
should not be holding up features that do exist for features that don't.
Great thread and very insightful. Yes; please make this more
accessible to other reviewers. Adding this to the wiki is a great
start.
Andrew
Mirantis
On Wed, Nov 6, 2013 at 11:05 AM, Pitucha, Stanislaw Izaak
stanislaw.pitu...@hp.com wrote:
How about putting it on a wiki and linking it from the
I've created blueprints for Fuel VMware hypervisor integration [1] and Fuel
modularization [2] and would appreciate any feedback.
Supporting a new hypervisor in Fuel creates some points on the current
methodology that need to be refactored in order to be able to provide for
multiple providers,
The openrc file has to be up to date for some of the HA scripts to
work, we could just source that.
On Fri, Jun 20, 2014 at 12:12 AM, Sergii Golovatiuk
sgolovat...@mirantis.com wrote:
+1 for #2.
~Sergii
On Fri, Jun 20, 2014 at 1:21 AM, Andrey Danin ada...@mirantis.com wrote:
+1 to Mike.
Should we also have the 25th as review day so we can squish those down too?
On Fri, Jun 20, 2014 at 6:30 AM, Mike Scherbakov
mscherba...@mirantis.com wrote:
Fuelers,
we need to group and enforce bug squashing activities on Tuesday, as
discussed on IRC meeting this Thursday [1]. Feel free to do
and ML2 plugins upstream support
and target it for future releases. This implementation spec is in fuel-specs
here: https://review.openstack.org/#/c/99807/ under work by Andrew Woodward
(@xarses) and should be moved to this blueprint. AFAIK, he is experiencing
problems with implementation
I agree with Evgeniy on this we should be able to build the your test, env
easily enough to accommodate this. If we cant then we should spend time
there since AFAICT it overlaps with user ask
1. Disable authentication
we should be able to set them to a known option with a config drive or
Teams from MElanox and VMware based their work on current implementation
of Neutron
Mlnx appears to not set any neutron settings, so wont be enabled correctly
with out some more TLC
(
https://wiki.openstack.org/wiki/Mellanox-Neutron-Icehouse-Redhat#Neutron_Server_Node
)
NSX appears to be
Ubuntu HA CI was experiencing intermittent issues, probably from
Now commit https://review.openstack.org/#/c/105433/ was merged with
failures from Ubuntu HA and now completely breaks the puppet catalog in HA
installs with:
Puppet::Parser::AST::Resource failed with error ArgumentError: Cannot
Sorry, HA was failing intermittently to
https://bugs.launchpad.net/fuel/+bug/1338594
On Wed, Jul 9, 2014 at 12:41 PM, Andrew Woodward xar...@gmail.com wrote:
Ubuntu HA CI was experiencing intermittent issues, probably from
Now commit https://review.openstack.org/#/c/105433/ was merged
After digging through this a little more, I found that
https://review.openstack.org/#/c/105791/ is proposed to fix the issue and
is passing CI.
On Wed, Jul 9, 2014 at 12:43 PM, Andrew Woodward xar...@gmail.com wrote:
Sorry, HA was failing intermittently to
https://bugs.launchpad.net/fuel/+bug
/job/master_fuellib_review_systest_ubuntu/1608/
Thanks,
On Wed, Jul 9, 2014 at 10:31 PM, Andrew Woodward xar...@gmail.com wrote:
Teams from MElanox and VMware based their work on current implementation
of Neutron
Mlnx appears to not set any neutron settings, so wont be enabled
correctly
-on-existing-network
On Fri, Jul 11, 2014 at 12:08 AM, Andrew Woodward xar...@gmail.com wrote:
Retested today
ubuntu single nova vlan - works
centos single nova dhcp - works
ubuntu single neutron gre - works
centos single neutron vlan - works
centos ha(1) neutron vlan - fail haproxy issue
ubuntu
[2] appears to be made worse, if not caused by neutron services
autostarting with debian, no patch yet, need to add mechanism to ha
layer to generate override files.
[3] appears to have stopped with this mornings master
[4] deleting the cluster, and restarting mostly removed this, was
getting
to [7]
[7] https://bugs.launchpad.net/puppet-neutron/+bug/1343009
CI is passing CentOS now, and only failing ubuntu in OSTF. This
appears to be due services not being properly managed in
corosync/pacemaker
On Tue, Jul 15, 2014 at 11:24 PM, Andrew Woodward xar...@gmail.com wrote:
[2] appears
reproduce. Also, it may be related to puppet ordering issues thus trying to
start some services before some others. As [2] is the only issue you are
pointing at now, let's create a bug and track it in Launchpad.
On Thu, Jul 17, 2014 at 11:20 AM, Andrew Woodward xar...@gmail.com
wrote:
[2] still
Mike,
I don't think we should SCF until the review queue is addressed, there are
far to many outstanding reviews presently. I'm not saying the queue has to
be flushed and revised (although we should give this time given the size of
the outstanding queue) , but all patches should be reviewed, and
There has been an increased occurrence of using [tag] in the title instead
of adding tag to the tags section of the LP bugs for Fuel.
As we discussed in the Fuel meeting last Thursday, We should stop doing
this as it causes several issues
* It spams e-mail.
* It breaks threading that your mail
Recently in one of my changes [1] I was fighting with one of the unit
tests showing a failure for a test which should have been outside the
sphere of influence.
Traceback (most recent call last):
File
/home/andreww/.virtualenvs/fuel/local/lib/python2.7/site-packages/mock.py,
line 1190, in
:
http://xsnippet.org/359888/ (with logging of SQL queries enabled)
I hope this helps. I'm just wondering, why would you want to call
refresh() there?
Thanks,
Roman
On Sat, Apr 12, 2014 at 1:33 AM, Andrew Woodward xar...@gmail.com
wrote:
Recently in one of my changes [1] I was fighting
Roman,
the current stable/4.1 has some fixes that make this less likely to
occur and is the most likely to recover.
That said, I've done some tracing and there are some issues with
nova-conductor processing those messages. Some of the times I've seen
the compute-node be the issue, other times
Correct. Openstack HA
On May 12, 2014 12:43 PM, Mike Scherbakov mscherba...@mirantis.com
wrote:
A little note - it's going to be about OpenStack HA issues, not about Fuel
master node HA, right?
On May 12, 2014 8:37 PM, Vladimir Kuklin vkuk...@mirantis.com wrote:
Fuelers,
We are going to
Using the keystone client is currently quite painful for fuel. For
example getting tokens from a fuel env when auth required (which is
needed if we want to use curl or other clients) is currently quite a
mess.
In order to get a token you can
python EOF
from fuelclient.client import Client
Should we just block the deployment until the NTP is fixed so they
know they need to fix it?
On Wed, Nov 12, 2014 at 6:06 PM, Stanislaw Bogatkin
sbogat...@mirantis.com wrote:
Hi all,
Today we have a next workflow about NTP in Fuel:
1. When someone deploy a master node, we need to somehow
neophy,
This is a requirement of the fuel deployment with vCenter selected as
the compute hyper-visor. In this case the nova-compute service would
be configured on the controller nodes and the fuel ui would not allow
you to deploy kvm computes.
You can post configure additional services on the
Some comments inline
On Tue, Nov 18, 2014 at 3:18 PM, Andrew Beekhof abeek...@redhat.com wrote:
Hi Everyone,
I was reading the blueprints mentioned here and thought I'd take the
opportunity to introduce myself and ask a few questions.
For those that don't recognise my name, Pacemaker is my
On Wed, Nov 12, 2014 at 4:10 AM, Aleksandr Didenko
adide...@mirantis.com wrote:
HI,
in order to make sure some critical Haproxy backends are running (like mysql
or keystone) before proceeding with deployment, we use execs like [1] or
[2].
We used to do the API waiting in the puppet resource
In order for this to occur, this means that the node has to be
bootstrapped and discover to nailgun, added to a cluster, and then
bootstrap again (reboot) and have the agent update with a different
nic order?
i think the issue will only occur when networks are mapped to the
interfaces, in this
So as part of the pumphouse integration, I've started poking around
the Plugin Arch implementation as an attempt to plug it into the fuel
master.
This would require that the plugin install a container, and some
scripts into the master node.
First look:
I've looked over the fuel plugins spec [1]
, Andrew Woodward xar...@gmail.com wrote:
So as part of the pumphouse integration, I've started poking around
the Plugin Arch implementation as an attempt to plug it into the fuel
master.
This would require that the plugin install a container, and some
scripts into the master node.
First look
On Tue, Nov 25, 2014 at 1:39 AM, Evgeniy L e...@mirantis.com wrote:
On Tue, Nov 25, 2014 at 10:40 AM, Andrew Woodward xar...@gmail.com wrote:
On Mon, Nov 24, 2014 at 4:40 AM, Evgeniy L e...@mirantis.com wrote:
Hi Andrew,
Comments inline.
Also could you please provide a link
I think it's necessary to start a working group for plugins and meet by
weekly until issues like these are flushed out of the design
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
Pawel,
I'm not sure that it's common at all to move the deployed cloud.
Hopefully fuel made it easy enough to deploy that you could simply
reset the cluster and re-deploy with the new network settings. I'd be
interested in understanding why this would be more painful than
re-configuring the
Bogdan,
Do you think that the existing post deployment hook is sufficient to
implement this or does additional plugins development need to be done to
support this
On Dec 30, 2014 3:39 AM, Bogdan Dobrelya bdobre...@mirantis.com wrote:
Hello.
There is a long living blueprint [0] about HA fencing
+1 we need more net testing pre deployment to recommend usable network
settings the first time. Settings like mtu gro gso need to be considered
too
On Dec 16, 2014 8:30 AM, Sergey Vasilenko svasile...@mirantis.com wrote:
Guys, it's a big and complicated architecture issue.
Issue, like this was
On Fri, Feb 6, 2015 at 11:16 PM, Mike Scherbakov mscherba...@mirantis.com
wrote:
Dmitry,
thanks for sharing CLI options. I'd like to clarify a few things.
Also very important to understand that if task is mapped to role
controller, but node where you want to apply that task doesn't have
help?
On Wed, Jan 28, 2015 at 8:49 PM, Andrew Woodward xar...@gmail.com
wrote:
Vova,
Its great to see so much progress on this, however it appears that we
have started merging code prior to the spec landing [0] lets get it
sorted ASAP.
[0] https://review.openstack.org/#/c/113491
[from another thread]
On Wed, Jan 14, 2015 at 2:24 AM, Igor Kalnitsky ikalnit...@mirantis.com wrote:
Guys,
We want to introduce an empty role as a basis for plugins. For
instance, the user select nodes, assign empty role and names it
somehow like CONTRAIL. In this step, vanilla fuel will
neophy,
It seems like there are left overs that fuel was using in the config
that would not be present when you installed neutron fresh. I'd
compare the config files and start backing out bits you dont need. I'd
start with the lines refrencing br-int, you dont need them on nodes
that aren't using
approc,
It's awesome to see the interest in getting CentOS 7.0 support. As
Sergii noted, the Mirantis team doesn't have enough bandwidth to
certify CentOS 7.0 for Fuel 6.1 however I would love to help you get
started with some of this.
The barriers to moving between versions usually are:
a)
My understanding is serverspec is not going to work well / going to be
supported. I think it was discusssed on IRC (as i cant find it in my
email). Stackforge/puppet-ceph moved from ?(something)spec to beaker,
as its more functional and actively developed.
On Mon, Jan 12, 2015 at 6:10 AM, Sergii
On Thu, Jan 15, 2015 at 3:11 AM, Andrey Danin ada...@mirantis.com wrote:
Answers inline.
On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L e...@mirantis.com wrote:
Hi,
Empty role is ready [1], thanks to granular deployment feature
I didn't have to hardcode some hacks in Astute again.
But there
Bogdan,
Yes I think tracking the bugs like this would be beneficial. We should also
link them from the BP so that the imperilmenter can track them. It adds
related blueprints in the bottom of the right column under the
subscribers so we probably should also edit the description so that the
data
On Thu, Feb 12, 2015 at 3:59 AM, Tomasz Napierala tnapier...@mirantis.com
wrote:
On 10 Feb 2015, at 23:02, Andrew Woodward xar...@gmail.com wrote:
previously we used squid in 3.0 and before. The main problem is that the
deployment would proceeded even if not all the packages where cached
There where some questions regarding direction for this on the fuel meeting
today. Can you elaborate on the status?
On Thu, Feb 12, 2015 at 12:01 PM, Andrew Woodward xar...@gmail.com wrote:
On Thu, Feb 12, 2015 at 3:59 AM, Tomasz Napierala tnapier...@mirantis.com
wrote:
On 10 Feb 2015
or non ha cluster in case of new release there
should
be only ha, and in case of old releases there should be ha and multinode.
Thanks,
On Mon, Aug 25, 2014 at 8:19 PM, Andrew Woodward xar...@gmail.com
wrote:
Started a new thread so that we don't hijack the older thread.
as
Andrew
are absolutely difficult to maintain is
crazy.
Vladimir Kozhukalov
On Tue, Jan 27, 2015 at 3:03 AM, Andrew Woodward xar...@gmail.com wrote:
On Mon, Jan 26, 2015 at 10:47 AM, Sergii Golovatiuk
sgolovat...@mirantis.com wrote:
Until we are sure IBP solves operation phase where we need to deliver
On Wed, Jan 28, 2015 at 3:06 AM, Evgeniy L e...@mirantis.com wrote:
Hi,
+1 for having primary-controller role in terms of deployment.
Yes, we need to continue to be able to differentiate the difference
between the first node in a set of roles, and all the others.
For controllers we have logic
On Mon, Jan 26, 2015 at 10:47 AM, Sergii Golovatiuk
sgolovat...@mirantis.com wrote:
Until we are sure IBP solves operation phase where we need to deliver
updated packages so client will be able to provision new machines with these
fixed packages, I would leave backward compatibility with normal
There are two threads here that need to be unraveled from each other.
1. We need to prevent fuel from doing anything if the OS is out of
disk space. It leads to a very broken database from which it requires
a developer to reset to a usable state.
From this point we need to
* develop a method for
Sorry for the necro-post but I think it's important to note that as we
get more progress with granular roles, we get specific tasks, and
time-out durations for not just plugin tasks, but all tasks. As
Evegniy noted, we should be able to use this as a calibration of the
ceiling of the progress
Here is a list of the issues I ran into using IBP before the 23rd. 5
appears to not be merged yet and must be resolved prior to making IBP
the default as you can't restart a provisioned node.
1. a full cobbler template is generated for the IBP node, if you
wanted to re-prov the node, you would
previously we used squid in 3.0 and before. The main problem is that the
deployment would proceeded even if not all the packages where cached or
even available on the remote. This often lead to broken deployments that
where hard to debug and a waste of alot of time. This _MUST_ be resolved or
we
vkuk...@mirantis.com
wrote:
+1 to Andrew
This is actually what we want to do with SSL keys.
On Wed, Feb 11, 2015 at 3:26 AM, Andrew Woodward xar...@gmail.com
wrote:
We need to be highly security conscious here doing this in an insecure
manner is a HUGE risk so rsync over ssh from
We need to be highly security conscious here doing this in an insecure
manner is a HUGE risk so rsync over ssh from the master node is usually (or
scp) OK but rsync protocol from the node in the cluster will not be BAD (it
leaves the certs exposed on an weak service.)
I could see this being
Rob,
This is of limited value to my business due to the GPL license -- so my
company's lawyers tell me. I will be unable to take advantage of what
looks to be a solid solution from what I can see of Zabbix. Are there any
risks to Fuel (open source contamination) from this approach? I
On Tue, Nov 25, 2014 at 5:21 AM, Bartosz Kupidura
bkupid...@mirantis.com wrote:
Hello All,
Im working on Zabbix implementation which include HA support.
Zabbix server should be deployed on all controllers in HA mode.
This needs to be discouraged as much as putting mongo-db on the
the warning? that way once asserted it won't re-raise the
error.
On 01/05/2015 10:40 PM, Andrew Woodward wrote:
There are two threads here that need to be unraveled from each
other.
1. We need to prevent fuel from doing anything if the OS is out of
disk space. It leads to a very broken database
While working to remove deps on /root/openrc [1][2], I found that we have a
package for fule-utils to provide a tool called fdb-cleaner. It looks like
the source is [3] and its built at [4]
I see that there are no tests, or CI to test integrity of the code there. I
propose that we move this to
The last couple of meetings have been visibly low on participation. Most
notably anyone not involved with the planned schedule is not participating.
Often I find that the discussion leeds to wanting to talk with more of the
devs, but they are frequently not available.
Is there any reason for the
On Mon, Mar 16, 2015 at 4:35 PM, Andrew Woodward xar...@gmail.com wrote:
While working to remove deps on /root/openrc [1][2], I found that we have
a package for fule-utils to provide a tool called fdb-cleaner. It looks
like the source is [3] and its built at [4]
I see that there are no tests
-agent-cleanup [5]
[5] https://review.openstack.org/#/c/158996/
On Tue, Mar 17, 2015 at 4:17 AM, Andrew Woodward xar...@gmail.com wrote:
On Mon, Mar 16, 2015 at 4:35 PM, Andrew Woodward xar...@gmail.com
wrote:
While working to remove deps on /root/openrc [1][2], I found that we
have
Right now, we create pools for images, compute, volumes, and radosgw
creates a bunch, all are assigned to the default crush map.
from the Ceph side, In order to create a pool where we could separate
it from another pool is to create a ruleset in the cursh map to
isolate the devices, then the
we already have a package with the name fuel-utils please see [1]. I
-1'd the CR over it.
[1] http://lists.openstack.org/pipermail/openstack-dev/2015-March/059206.html
On Thu, Mar 19, 2015 at 7:11 AM, Alexander Kislitsky
akislit...@mirantis.com wrote:
+1 for moving fuel_development into
Looks good, a couple of things:
Is there a reason that the nodes near to top didn't render in the role group?
Can you render a message like deployment failure, or deployment success?
Can you render the networks or settings page?
On Mon, Mar 23, 2015 at 10:36 AM, Vitaly Kramskikh
Sounds good, lets ensure that we create a blue-print in LP and some form of
initial spec with the expected design
On Wed, May 13, 2015 at 9:38 AM Jay Pipes jaypi...@gmail.com wrote:
++
On 05/13/2015 11:57 AM, Swann Croiset wrote:
Hi Fuelers,
It would be valuable to configure the
On Thu, May 7, 2015 at 5:01 PM Andrew Beekhof abeek...@redhat.com wrote:
On 5 May 2015, at 1:19 pm, Zhou Zheng Sheng / 周征晟
zhengsh...@awcloud.com wrote:
Thank you Andrew.
on 2015/05/05 08:03, Andrew Beekhof wrote:
On 28 Apr 2015, at 11:15 pm, Bogdan Dobrelya bdobre...@mirantis.com
On Wed, May 6, 2015 at 4:06 AM Emma Gordon (projectcalico.org)
e...@projectcalico.org wrote:
If fuel plugin code is checked into a stackforge repository (as
suggested in the fuel plugin wiki
https://wiki.openstack.org/wiki/Fuel/Plugins#Repo), who owns that code?
Disclaimer, I'm not a
)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
OpenStack
Since the meeting was closed prior to having a discussion for this topic, I
will post my notes here as well.
I will start updating some of the BP's that have landed in 6.1 to reflect
their current status
There are a number of specs open for BP's that have code landed. We will
merge the current
__
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
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
-bin/mailman/listinfo/openstack-dev
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
Also in favor of #2 and thought it was how it was running. #4 sounds bad
and may hide good code.
How do we want to account for drive-by authors who are going to be unable
to work on future revisions. We talked a while back that we wanted to be
able to account for this as some operators are unable
Samuel,
VXLAN was moved to 7.0, as you noted it won't make 6.1. Mirantis has
identified this as a high priority for 7.0 so it should get more attention
this time. However any assistance in CR / Testing is always appreciated.
On Thu, May 28, 2015 at 1:38 PM Samuel Bartel
__
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
--
--
Andrew Woodward
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
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
, Andrew Woodward wrote:
Zhou,
As mentioned, Please review [1][2]. This is the interface we will
support as we implement the advanced networking parts. In your case, just
fip the role map in your patch to nailgun and the library interface will
remain the same.
[1] https
Please note the IRC meeting is scheduled for 16:00 UTC in
#openstack-meeting-alt
Please review meeting agenda and update if there is something you wish to
discuss.
https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph
?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
OpenStack Development Mailing List (not for usage questions
(not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
Gelbukh
__
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
--
--
Andrew
__
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
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
Samuel,
I cases like glance, and nova, you will likely want the volumes still
because they are still used in some cases as cache(glance), operational
files(nova-compute), or even interim storage(nova-compute) of snapshots. We
keep them around even when we use Ceph.
In the case of cinder, I'm
As we chase the release of Fuel 6.1, it's time again to start thinking
about you want to see landing in 7.0
There are a few blueprints [1] already tagged for 7.0 but even more tagged
to next.
If you have something that you would like to see land in 7.0, you should
create a spec and blueprint
We found that we where having problems getting in sync with where everyone
was for actions to get the kilo packages merged. Here is the summary from
the meeting
https://etherpad.openstack.org/p/fuel-kilo
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
negative feedback.
[1] https://review.openstack.org/#/c/179645/
[2] https://review.openstack.org/#/c/195959/
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
OpenStack Development Mailing List
away and they can adapt to the new
interface before it's the only interface available.
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
__
OpenStack Development Mailing List (not for usage questions
1 - 100 of 201 matches
Mail list logo
